 Thanks for joining us today for this edition of the Agile India interview series. We're hosts Chris Edwards and Sean Dunn. Agile India 2017 is Asia's largest and premier conference on Agile and Lean. This year's conference will take place in Bangalore starting on Monday, March 6th, where experts and practitioners from around the world will share their experience. For more information, you can see our website at 2017.agileindia.org. Our guest today is author, trainer, conference speaker and Agilist Woody Zool. Woody is more than 35 years of software development experience and over 20 of those as an extreme programmer. Woody is a co-author of the book Mob Programming, a whole team approach and is well known as a participant in a discussion around no estimates. Woody, thanks for joining us today. Well, thanks for having me. This is great. I figured maybe we could start delving into the more controversial topic, no estimates. Sure. Estimation is one of these things that I think we take for granted and granted in our everyday work. I was wondering if you could talk about your involvement in the origination of the no estimates hashtag and what led you to originally start questioning this practice of estimation? That's a good way of saying it. No estimates itself is a hashtag that just emerged out of a conversation in Twitter that we were having between three or four of us in 2012, I think. Up to that point though, I had discovered in doing a talk that I had done a handful of times that estimates are a touchy subject. That talk I used to do, I had several names for it, but the best name I had was Agil Success and the reason that I was giving that talk would be that people would, you know, I'd have some kind of good success on a project and people say, could you come and talk to our group about that? So in giving that talk, one of the slides, one of many slides about how can we be successful doing software development, one of the slides was we should be questioning anything that we're doing that we are just accepting as something we have to do without questioning. And one of the items on the list was estimates. So I would just go down the list. I don't remember what the other items were right now, but it could be something like, you know, weekly meetings or whatever. And when I got down to estimates, it would seem like all of a sudden, the audience would be stirring. They all wanted to be part of this discussion instead of just listening to the talk. They wanted to express why they felt estimates were important. And interestingly, if there was let's say two or three people who really wanted to talk and I'd give them a chance to, they would have three different reasons why estimates were important and they would start arguing with each other as to why it's not needed for your use of them, but it's really needed for my use of them. And so that just showed me that this is a hot topic that maybe we need to dig a little deeper. When it starts bubbling up like that, it's maybe more serious than I thought it was. So I spent a few hours after the first time that happened reflecting on it and starting to come up with some of the concepts about how do we question these things and why should we question them. And of course, I had already found by that time that estimates are not often needed in the places we think we need them. So it was easy enough for me to talk about it and that's about it. So it just, it started that way and it was in 19, I mean 2012 that the conversation in Twitter started heating up. Vasco Duarte was speaking about, he was asking people, can you share stories of wastes with estimates that you've seen? And Neil Killick was speaking about some of those things too and everybody was starting to write blog posts. So I shared my little bits of my thinking about it. And interestingly, Ron Jeffries, I believe, had joined in the conversation and asked me to write a blog post about an experience I had where we didn't use estimates for time, cost, or effort for writing some software. And I wrote that blog post and to post it, I used this hashtag that we were just, I just coined there, of no estimates. And that really, I think that invited a lot of people to the conversation. All of a sudden it became quite a bit more active. And so I ran with that. It's like, let's have this conversation. I'm in dying to have this conversation for years. So that's about it. I think that's the beginning of the hashtag in a way. Like I didn't necessarily do that to be controversial. It's just the controversy was bubbling under the surface. And it came for free by using the hashtag, I got a whole bunch of free controversy. Do you think, I mean, it certainly turned into a controversial topic, following it on Twitter and social media and on the blog posts. Where do you think the controversy has gotten us? Has it been a productive conversation? Do you feel that we've benefited from a deeper understanding through the conversation? Or perhaps it's been maybe a little bit less productive than it could have been. I'm kind of curious to know your thoughts on that. That's a really good line of thinking there because I really have no way of knowing what might have happened if we didn't stumble upon calling it no estimates. But to be really clear, my whole purpose in tweeting about it was I noticed that Vasco and Neil had been tweeting. And I go, hey, here's some people who want to talk about the same thing that I've been wanting to talk about. And I welcomed that. So by using that hashtag, what would generally happen is at that time, three, four years ago, I was tweeting out every week or so, sometimes a couple of times a week, that I'm open to having a Skype conversation with anybody who wants to talk about mob programming, estimates, no estimates, problems with estimates, and maybe in general in general. So I was often getting people willing to have a hour or a half hour Skype conversation. And what I found was that anybody who was attracted to the no estimates hashtag was ready to have some kind of a conversation. And so if we could have a face-to-face Skype style conversation, then we could actually have some real progress. So I think it's been a great thing. I've actually talked with now several dozen people who are actually using various ideas related to no estimates in their daily work and in their companies. Some of them not tiny, some of them pretty big. And I've also found that a lot of people who started out saying, well, no, we absolutely need estimates, have turned into people who are now willing to explore these other possibilities. The point is, I was wanting to have the conversation because I want to learn more, and that opportunity came. I'm not even partly considering as an industry that we need to change. I'm not even considering that any particular company needs to change. Only that I'm interested in learning more about this and having a conversation with other people who are also interested in the same topic. I think what I found interesting is I've got a background as a developer and seeing firsthand how estimates can lead to behaviors that may be undesirable and maybe the people who are asking for estimates don't realize that these can lead to people feeling like they're under more pressure and having these strict deadlines. And I'm thinking if they do add value, there's something we could replace them with that wouldn't have these other impacts. So that's a good question. So a big part of the first few rounds of discussing this was what are possible alternatives to estimates? But that's not really a conversation that's very interesting to me. I think we need to go up a step. So the steps saying, well, what could we do instead of estimates? I want to ask the question, what are the kinds of decisions that we are making that we feel we need to have estimates to be able to make that decision? The basic point is that estimates themselves might not be serving the purpose to which we put them, but maybe the purpose is wrong. So we have to first investigate what are the kinds of decisions we need to make? What are the kinds of decisions that I want to make? And how do we deal with that? Are they necessary? Why are we using these kinds of decisions? And one typical one that I used to hear early on was should we do Project A or Project B? How would we make that decision? So a very high-level, meta-level question would be do we need to decide that? Why do we feel we need to decide that? What is the purpose in making a decision like that? And there's a really easy answer, but I don't think the easy answers are usually the right ones. And that easy answer is, well, we don't have enough money to do both projects, so we have to decide which project to do. But that really leaves out a lot of the nuances. For example, well, maybe we could do a part of each project, and then we will get some of the benefit of both. Why do we think we need to do one over the other? Another reason we sometimes use estimates is to prioritize things. Are we going to do the things that provide more benefit for the value? I think that's interesting because even when you're talking about Project A versus Project B, it's thinking about things as discrete units that you have to complete. And often I think it's a challenge for people to think about how can you split something that's a year long down smaller, but now we see companies delivering software on the order of days or seconds, which I think is something we never could have envisioned a decade ago. Even a decade ago I was working on things where people were doing essentially a delivery as soon as something was ready to be delivered, which could mean several times a day. Not second by second because a lot of the tooling and stuff that we didn't necessarily have. But I even recollect, first of all, in my very earliest days of writing software, where I was mostly writing it for myself, that I could write something and let's say I spent an hour on something, if it added a little bit of value to what I was writing, I could start using it. And so that I think thinking almost every developer has done something like that. Let's say early on, like one of the things everybody kind of did early on, and I'm talking in the 80s, once you get your hands on a computer relatively cheaply, was to write some software to help them manage things like their appointments or their checkbook. Or I knew a guy who wrote software that would act as a word processor and he did all his schoolwork on a word processor he wrote himself because the word processors you could buy in those days in the early 80s or late 70s would have cost you a lot of money and they weren't very good. So we would just say, okay, I'm writing this little bit of software for myself. I can use it as I write it. So like Chris, I've come from a developer background, but I've also been a product manager before. So I can appreciate the value of estimates to some degree as a product manager, even when you've got a team who's developing incrementally because you kind of want to have some sense of, okay, what I'm asking for or what I think I might be asking for today is that going to take me an hour? Or am I asking for something that's going to be a two month adventure? And that kind of feedback I thought was really valuable from the team and then to have it included in that process. But what I think maybe the elephant in the room is is when we treat estimates as this passive aggressive motivational tool when the estimates turn into the commitments or if we try and treat them with a false level precision we're making decisions based on them, assuming that they're far more precise than they actually are. And I'm kind of curious to know what your thoughts are on, is that a problem we see how they're used when they turn into commitments? That's part of the questioning we have to do is how are we using them and are they serving that purpose for us. So when we use them in what I would consider a dysfunctional way, which is purposefully dysfunctional, like, boy, if we can get a commitment from these people then we can hold them to that. And I've actually heard managers say, look, you said it would take three hours, you got to work until it's done because you've already used up your three hours. But I've seen worse dysfunctions than that as well. But those are just bad behaviors regardless. I'm really concerned with the idea that, for example, you were saying, I want to get an idea how long this will take so we can make some decisions. So it's like, if it's going to take us an hour or two, that's very different than if it's going to take two months. Well, if I, the person asking for that estimate, can't make that judgment myself, I might need to become better at my job. If I can't make those judgments to myself and I have to ask a developer for that, I may not be ready for managing software development projects. That would be a question I would want to ask myself. I've owned a number of small businesses over the years. If I wasn't competent in any of those businesses, I probably shouldn't have been owning them and running them. It's like I had to know a lot about it. The developer is only knowledgeable about a very small part of the nature of this bit that we're working on. They know about writing the code for something that they may not yet understand. How long are we going to give them to get a good understanding of what it is we're asking them to give us an estimate for before they would be comfortable saying, yeah, I have a good handle on this. I can give an example of that. I was on a project a few months ago where I was consulting with some people and the product expert had come in. They were just getting ready to deploy something. The product expert had come in to say, we've got this one other little thing we'd like to get in before we deploy it. Can we do that? And he explained what it was. And somebody on the team said, oh, yeah, that'll take me a couple hours. I'll do that. I'll get right to it. Boy, I didn't feel comfortable saying stop, stop, stop. Let's talk about this first. We're ready to deploy something almost, and you want to introduce something new to it. The funny thing is, is that anything we introduce into existing work is going to introduce complications that we can't know. So in this particular case, something somebody thought they could do in two hours did not take two hours. It took about two weeks. And the two weeks did not end up with us, with them finishing that chunk of work. What it ended up with them is determining it wasn't possible in the framework that we had. They were imagining a different framework that they had more experience with. And they just assumed that the framework that they were working in today would have that same feature. So now the decision becomes, after two weeks, what do we do? Do we write this feature into the framework so we can actually have it? Do we switch to the other framework, which means we have to rewrite everything else? How are we going to handle this? So every little bit that we add influences the possibilities for the future. So we start with a project. We start writing some stuff. And then each bit that we add changes how we can work with it in the future. I think your connection to clean code is interesting because I've definitely seen cases where the conversation around estimates is more around how easy is this to do in our code base. You know, the product manager is exploring these things they want to do and they're getting back from the developer. Well, yeah, okay, that's got some scary code there. That's going to take a long time. And which kind of leads into this sort of more responsibility of development to build in that clean code. And I guess you have a lot of experience in extreme programming. So what have you seen has been some of the important things that can help enable that in a development team? Well, first of all, you need to have people who are actually willing to explore how can we make things better? And this is a very environmental kind of a concept because in a lot of places that we work that's not valued. And so where even people have the desire to do that, they're not really allowed to do that. In other words, to scrutinize how can we make things better? Is the approach we're taking a good one and how can we prove it to ourselves that it is and things like that. So when we have an environment where we really are allowed to excel at whatever it is that we do, what our part of this is, then we can move towards ideas like having code that's very easy to maintain. And if we kind of blame ourselves and say, well, I'm a professional and therefore I should be able to do this without asking. And then we do that. And I've actually, I don't know, maybe you've experienced this. You see some code that's very hard to read. You factor it, making it easier to read. Check it in. And three days later, somebody's reverted it back to what it was before because they liked the way it was before. And so it's easy to take offense at somebody making their code better. And so you have to be very careful with these things. This is part of an environment of work that we need to figure out. How can we make it where it's easy for everyone to work on the code that we're writing today? Or tomorrow if we didn't quite hit it today? I love the example you used of software teams running into the problem of they assumed it was going to be easy in their old framework and then having the issue with the new framework. And that very much resonates with me and having to spend time doing software development when you run into these problems of oh, we made this very natural assumption that a third-party tool would allow us to do something or some existing code would make this easy to do and then the devils and the details you start doing it and you find out that's not necessarily the case and these things compound and expand and explode. But I think this speaks to the this just natural uncertainty of building new things. We are always building things we've never done before. That's right. Whether it's in a new framework there's always something new about it that adds this uncertainty. It seems however lots of organizations struggle with this concept of there's actually just uncertainty in the work of building new things and if you've got let's say a development team who expresses that well there's risk here, there's uncertainty here then that's some kind of like expression of unprofessionalism that all professionals should be certain about something. How culturally do you go about addressing that problem when you've got organizations who believe that there should be certainty here and if you can't provide me the certainty then you're just the wrong you're the wrong group of people. So we we definitely want things to be the way we dream they could be. So when somebody's doing managing a software project let's say it's a higher level executive in the company who really doesn't buy into the ideas that software is anything different than a typical manufacturing process then I'm not sure there's an easy way to approach that. I believe that over time we can we can take steps that will lead to us having more and more confidence in new ways of working that help eliminate these problems but first of all I would never assume that I can convince anybody of anything. The best I can do even with trying to take a really simple one I really like test driven development and I like it for at least two reasons. One is I feel much safer knowing that at least all the things I've written tests for I feel very certain that I will find out that I broke something immediately if I've done that. The other thing is it helps me think differently about my solution space how I'm going to solve this problem. I get to approach it in a very tiny steps and if I learn to be really good at taking those tiny steps there's a lot less what I would consider wasted energy trying to think through everything up front because when you get good at those tiny steps and refactoring to a better solution you begin seeing patterns right away when you do this tiny steps. So an example of tiny step is if you're going to do like a Roman numeral converter all you have to do is return back you pass in a one and you get back a Roman numeral I and your first test passes you can write the second test and the third test for one two and three and now you've already seen a pattern and you can refactor to a better way of doing that without ever breaking your tests and now as we add things and add things pretty soon we see the bigger patterns and eventually those patterns all express themselves instead of me having to imagine what the patterns might be so how do we convince I don't know how to do that but I learned this from a couple people a few years back just model behaviors that you believe in the things you think work and if it's actually useful to others they'll pick up on it if they're even partly interested they'll pick up on it I think something that I found interesting that you said earlier was you were talking about the situation where you know a programmer types some code they check it in and then someone else reverts it and what that reveals to me is there isn't a lot of agreement on the team about what is clean code and what are these practices and even when you're talking about test driven development you can get like almost religious wars over some of these topics but I've also seen that you've worked in environments that are hyper collaborative and you guys have developed things like mob programming and you've been able to overcome these very deep divides or maybe I guess I don't know but these divides exist in the first place and how have you seen teams be able to come to that type of conceptual clarity well that's a really interesting topic to me because I believe pretty deeply now that the normal way or the typical way is a better way of saying it the typical way I've seen people trying to improve things in their workplace is they look for the stuff that's broken and want to know how they can fix it and I learned from reading Kent Beck's book Extreme Programming Explained I believe it was in the first edition where he talked about the practices that he had confidence in he had confidence in them because at least the way he said it he had good experience with them and he imagined them as if they were the knobs on a control board and he imagined that he could turn those knobs up so we can ask ourselves that question what would it be like if we could turn everything up as far as we're allowed to you know as far as the control board allow it now clearly we want a balance but if something's good and something else is good and we turn them both up and there's no conflict in turning them both up then we win this is great if we can only turn one of them up a little bit and the other one a little bit that's good too so that's the beginning point for me this kind of was a I would consider this a a real eye-opener for me back in the 90s to really ponder the idea that what if we focus on just turning up the good what if we just looked for something that was good and said can we turn that up a little bit and we can just take it in baby steps that's another thing TDD is the same way we can take it in baby steps that's really a powerful thing why don't we shift gears a bit and dive a bit more into the topic of mall programming I'd like to ask a question about what it feels like to work in a mall because I think I understand the concept of it you've got multiple people working out the same computer in the same place on the same thing but I have a little bit of trouble visualizing what that experience is actually like so if I were to walk into the mob at Hunter what would I be experiencing so our original team is a little different experience than you would have there now because they have eight teams now when I was there from 2011 to 2015 I guess we had started with the one team as we originate the idea which was totally serendipitous it wasn't like we sat down and said you know pair programming is good let's turn it up by adding another person you know it was definitely studying together is a good thing let's do more of that and as we studied more and more together we became better and better at helping each other as a team and as we became better and better at helping each other as a team it became easier throughout the day to find ways to help each other so our study periods overflowed into our work as far as our attitude about our work but let's say that you were to step into Hunter today with the current environment and they've got the eight teams working and you went to work with the team what you would find is a group of people who are focused on probably a single product depending on which team and they start right in the beginning of the day with a study period at the end of that study period which takes about an hour they just begin their work and we're going to pick up right where we were yesterday and of course I no longer work there but I'm actually going to be there this weekend doing a workshop they're going to start in somebody saying well here's our next step and they'll go to their board they'll have a discussion about what they want to do and to be very clear mob programming isn't about four or five people watching somebody type mob program is about four or five people expressing their ideas sharing their intent coming up with what they think is a good next step and somebody at the keyboard translating that into code so it's really four or five people doing programming and one person writing the code that's kind of two different ways of thinking about what we're doing it's separating the solution and problem space from the code space the person at the keyboard is freeing up everyone else to pay attention to the solution and the problem space so they're not constantly context switching into the code space now we're all paying attention to the code that's going in but it's not our primary area of attention the primary area of attention is the solution we're devising so what you'll find is rather than you sitting down with a group of people and having to come up with all the ideas you just have to be paying enough attention to hear the ideas as they come out and add your value to them when it's appropriate to do so so we're looking for a team that can work well together but each of us can contribute value that there isn't anyone else on the team to contribute that so we get sort of the best of everybody into our code and none of the worst of anybody when I first heard about mob programming it seemed to be this this contradiction because you know we're having more people there it's going to be less efficient right like more people at a keyboard yet when I hear people from Hunter talk about it they talk about how they've never been more productive so how do you reconcile that contradiction yeah so this is an interesting thing so I'll give you this one example let's say I'm sitting at the keyboard and I'm working with a framework that somebody else in the company knows something about that's a specifics maybe we wrote it internally but I wasn't part of the team that did that and I'm going boy how do I use this I get out the documentation I'm going boy I don't get this now I've got to get up and find somebody who can explain it to me when I find that person well let's say the first one I find isn't really the right one but they might be so I start talking to them you know you need to talk to Mary she's the one who really knows this so now I've got to go find Mary I've already disturbed one person and now I'm going to go disturb someone else when I go find that other person I'm going to ask my questions and they're going to say yeah I don't really have time to go into that right now but how about we make a meeting for tomorrow morning so we're putting ourselves into these answer question cues we're going to cue to get an answer for something and now we can't proceed until we get the answer and now we're waiting if Mary was already in my context working right there next to me she would have anticipated my question and before I even asked it she would have provided the direction that I would have needed so while it doesn't seem to make a lot of sense that five people working together might be more productive what we noticed and I've talked to many teams that notice this as well now is that we get through stories really quickly so let's say a team of five people for two weeks on a sprint and they've taken on six stories to get done and they get six stories done we notice when we're working as a team like this we're getting those stories done in an hour or two so a lot of this starts happening if we're contributing just the right thing at just the right time the whole team together has a flow that we can't get when we're working individually now I'm not suggesting this would work anywhere it happened to work for us it happened to notice that so that's really two important things you got to try things and pay attention so you can notice when they're good and if you don't try things you can talk about it all you want but if you don't try it you're never going to be able to notice whether it's working for you or not and once you start trying things you really got to be paying attention what was good, what can we turn up about that and I think that's a really good this trying things as much as I find mob programming fascinating, what I find more fascinating is what is it about these context, these organizations these environments that people are working in that allows them to discover mob programming that allows them to discover scrum in the first place I think the first line of the manifesto is the most underappreciated we are discovering new and better ways of developing software by doing it so what was it that enables these things to be discovered in our particular case I was at a fortunate point in my career where I had built some credibility as an Agilist if that's the term and I had a good job and that job was actually quite wonderful and so when the job came along I was able to verify that it would have all the things that I would want to have a very innovative workplace and their byline at that time was the irrigation innovators because they are a producer of irrigation products but they were expanding their business a little bit they are not a tiny business they have a couple thousand people working there but they are a manufacturer but their model line actually changed in the last few years their byline now is built on innovation so that was one of the keys to me is to see that they used the word innovation in their company byline and so that was important to me and I would consider pretty important discussions about topics like that some meaningful discussions is what I meant to say with the people I would be working with and working for there is going to be allowed to be innovative and so there was a lot of things that we tried and we got a lot of support on that so that's really one of the things I think we require to make good progress in our work is that there is enough people on board with the idea that we can make things better and we are allowed to try to make things better and not everything is going to work let's try this and find it fails that's okay even if we didn't learn anything except for that thing didn't work okay I've watched a lot of people trying TDD test driven development for example and after a day or two they say this just isn't working very good for me well when I was a kid I learned to play the piano and then later I taught music lessons on guitar and stuff and anybody who would pick up a guitar and try it out for a couple days and say nah I can't play very good so this isn't for me we would all say well wait a second for a while this is like try it for six months boy you try something for two days I'm not sure we can learn anything so we had an environment where we could try things so what you kind of alluded to this idea a few minutes ago that before you went to Hunter you were looking for certain things you know these mental heuristics and I think you mentioned you know innovation being part of the tagline I'm curious to know what were some of these other mental heuristics that you go through to identify if a company's you know innovative or are going to allow you to do the types of experimentation that you think are necessary to create these innovative companies what else is there that's a tough one to answer for me because I think I've changed my philosophy slightly since then and I believe that if I go back over my career of actually working in companies prior to 1999 I was mostly self-employed I owned a small business or various small businesses and had employees when I decided to get into software I didn't want to start a software company when I decided to start working in software full-time I wanted to go to work for someone else so I could kind of learn the ropes and learn whether I liked it or not and so on so for a long time I had certain attitudes that were changing through the influence of people like reading Kent Beck and reading people like Ron Jeffries and Bob Martin and so on I was learning quite a bit and for a long time I felt we needed to find the right environment to be able to have the successes but if I look back over it now I've seen successes even in really bad environments where people weren't allowed to do the things where it wasn't easy for them to do the things that would make things better so right now if somebody were coming to me for example and saying hey in our company we're really open to some new ideas we want to learn to do mob programming we want to become good at that I would kind of rather have us, although I do mob programming workshops and I always bring this up in the workshops I want us to focus on what's the right approach for us in this context, in this company to make things better so our approach Hunter was we were learning to study together we were learning about different skills we were learning about the complete code and all that stuff and through good retrospectives that had good results it morphed into us doing mob programming but in another organization it could have been something completely different I think you might have answered another question I had which was there's sort of seems like a requirement of a really collaborative culture in mob programming or at least mob programming it is a collaborative activity first can you teach someone mob programming and then a collaborative culture will emerge from that or is it the other way around that's an interesting quandary because I don't think that there's a single path at all you remember that movie Jurassic Park and the mathematician guy what's his name anyways he drips the water on the paleontologist's hand and it goes off one way and the next time it goes off the other way so it's like it's micro tiny differences will lead to a different path each time if I walk up to the door and I'm going to go into the building and somebody behind me says hey Woody can I talk with you for a second my life is different than if I had just opened the door and walked in it's every bit of what we're doing it's a path that has so many different little nuances so I think that we take the steps and get good at paying attention and get ourselves a pretty good philosophy of how we're going to approach things and I like basically the basic agile philosophy which is expressed in the manifesto and the principles is sufficient for a lot of stuff but we have a good philosophy what programming is about is we need some practical way to turn our ideas into usable software or whatever it is we're doing and to be able to do that we have to innovate we have to discover so we have to get good at discovery and the practices that we're using today are simply are simply a stepping stone to the practices we'll use in the future what we have is every evolving set of every evolving practices the set of practices changes over the years and the way we use the particular practices come and go and within the practices themselves they modify if you go to somebody who's doing pair programming let's say on this team and you go over to another team they're probably working in at least a slightly different way and it's going to depend on the nature of the people doing the work and the type of work they're doing there's no easy way I think the basics is having a good philosophy and part of that is things like safety not being prideful about our abilities and things like that and we could probably, that metal area is the way really where the value comes in and there's a lot of people talking about these things and thinking about these things and presenting them at conferences we can't hardly avoid hearing about it it's so valuable to us people like linda rising is the one I like to use as an example because linda rising is talking quite a bit about the idea that most of the decisions if not all of the decisions we make are based on our emotions and our biases and not based on logic if we accept that idea there's a lot of things we better start considering doing differently and thinking differently about what we're doing and I kind of think it's probably true there's that old saying from Ben Franklin I think said something like being a rational human being because we can rationalize any decision we've made and stuff like that and so that's sort of what we do and that's like back to estimates it's a big part of why we use estimates well we decided to do this project because based on the information we had we felt we made a good decision that's decision based evidence making yeah, there you go and that's kind of sad and I think we can do a lot better than that but am I the one to do it I'm just a I'm stumbling down this path just like everyone else just a guy asking questions I am asking questions I really think there's a handful of really great questions to be asking and if we the place to start as an individual for me was to question the things that I had the most belief in the things I trusted the most the things that I thought were just rock solid I start realizing that's probably hiding my biggest problems so are you doing today that you're starting to question that maybe you hadn't a year or two ago so maybe a year or two ago I was just starting to question the idea of keeping teams together because a lot of the stuff about we hear about teams is once you have a good functioning team you want to keep them together and so that just seems so natural and correct so that's one of the things I've been experimenting with and considering that's the sort of thing but really my deepest beliefs right now are going to be very tricky for me to question because one of my deepest health beliefs is we've got a question our deepest health beliefs and so that's like going to be kind of recursive going down the rabbit hole kind of a deal yeah one of the things that I really have enjoyed lately is the idea of allowing beginners let's try their idea you know when we're doing a code cata or a coding dojo or something let's try the idea from the beginner trying to break them all that the more experienced person or break the model that the more experienced person is the one we should be listening most to well maybe let's experiment in the other direction let's see what happens you mentioned about safety and the importance of having safety and also how we're emotional beings and much of our decisions are based on emotion clearly leadership has a huge influence and I think you've as you mentioned you've held many manager and owner positions yourself by virtue of authority in the leadership position you have a huge influence on the organization and the people what advice would you have to let's say a new manager to build the type of organization that we think that we're going to need to be successful in the future yeah so first of all I don't really feel I'm that I'm the right person to give advice on anything but I could certainly give my opinion and I could talk about it for myself for many years I thought that I needed to think things through so I could help guide people that like in the case of let's say I had some employees in my own business that I felt that I needed to be able to guide them well and when I finally discovered that what's more important is to let them make the mistakes that I made for themselves they'll probably even discover better mistakes let them learn from their own mistakes and that took me years and years to learn that was really really valuable for me so my opinion for myself definitely is letting other people grow is a tough thing when we don't allow that to happen sooner or later everybody will have to come to you in this case to me for answers on everything because once you even say something like well this is fine but I'm going to give the final okay on it so go ahead and finish up and I'll give you your okay or not then we've already kind of lost the game they're going to stop trying things that could fail we have to make it again I'm going to say for myself I feel much more comfortable allowing ourselves to fail that speaks to me I've held a couple management roles myself and letting go of control and being okay if things go wrong it's very hard especially when you're a new manager there's a leap of faith there you want to impress you want to do a good job you want to show that you know what you're doing and you especially want to look confident and collected in front of those you lead so I guess I wonder how do you overcome that as a new person or not a new person but a new manager who's very maybe young and inexperienced and is that something that maybe just takes time to arrive at yeah that's really a problem because because our workplaces are not set up for us in most cases to be able to fail at things we expect successes or have successes expected from us you know just by default that's one of those things we need to be questioning if we're not taking risks it's a saying that you hear often if we're not taking risks we're probably not doing anything worthwhile if we're taking risks then things can fail and if everything we do has to succeed we're likely not taking any risks whatsoever and we're doing the most mediocre things we possibly can I say in most of the organizations I've worked in since I started working for other people I've seen a pretty standard setup where people are not really allowed to succeed or allowed to excel what they're naturally good at they're expected to get better at the things they're not very good at but they're not allowed to exercise the things they're really great at or will become great at and those are the kinds of things I like to pay attention to in fact I've even seen organizations and I never have gotten this where most of the performance review is about the things you need to improve instead of the things you're great at and how can we make it better and maybe in general there's a mindset that if we invest in the things we're not very good at we'll get more return than if we invest in the things we're already good at maybe that's a common viewpoint I'm not a researcher I'm not a scientist I'm not a professor so these are just my ideas thanks Woody I appreciate you spending time with us today was there anything else that you wanted to delve into before we wrap things up? Well we've covered a lot of good stuff here I think that this touches on the things that I'm really interested in I think the future for us is really about working well together so I think we kind of covered that and I think that the more we can be talking about that as our industry the better off we'll be I do have a couple things that I've been doing and I'm really looking for some exciting opportunities over the next year to do workshops for people so I want to make sure I mention that I've been doing them all around the world I haven't made it to every continent yet but I'm getting close and you have a book out now along with Kevin Meadows a good friend of mine a long time friend of mine who's also a software developer and has managed a lot of projects we worked together to write this book and I'm going to hold it up just so that people can see it it's not too reflective there it's in a printed form it's available in an electronic form only through LeanPub which is where we wrote it and it's pretty much done I think we've got it, you know we could say all the chapters we were thinking of putting into it are there we're tweaking a few things here and there I am thinking of turning it into a print book and I'm talking with some publishers but you can get it by just going to leanpub.mobprogramming or leanpub.com leanpub.mobprogramming it's a great little model for writing books the whole model of delivering little bits at a time it's sort of a very agile way of doing things and that's how we wrote the book we collaborated, that was another great thing throughout the whole thing we wrote each chapter together I'm not a writer what we did was just getting our stuff down best we could of a few chapters that you can take a look at it and we'll put a link to that on the video post here so our viewers can go follow that and see the book on leanpub that'd be great I appreciate you joining us today we appreciate everything you do for the community and we know you put a lot of your own time that you sort of donate into the community so we really appreciate that and thanks very much we hope to see you at Agile India 2017 thank you very much I'm honored to be interviewed here and yeah, that's great and thanks everyone for listening to the Agile India interview series this video was produced by Chris and Sean Agile you can find us on twitter at ChrisSeanAgile or our website www.christenSeanAgile.com thanks for joining us today and we hope to see you next time