Bill Wakes joining me, a 15 plus year veteran of the sport of Agile and a major thought leader and contributor in the space. Thanks for joining me, Bill. >> Alex, thanks. >> You do a lot of work with XP among other things. Can you talk a little bit about the rubric of Yagne and kind of where does that come from, why do we need to talk about that? And how does the ideas and discussions around that help teams be more effective? >> Sure, YAGNI stands for, you aren't going to need it or you ain't going to need it. And I think maybe Ron Jeffries probably put the acronym together from that first XP team. And it's really the notion to say how much should we plan now and implement now versus are we able to implement things later? So if you're in an environment, like start with a waterfall kind of thing, I'm going to define the whole system. And then, design the whole thing and then implemented and then the pieces will be there were using them. And you can kind of get a mind set that it's says, you have to build this whole data based interface layer before I start anything else. And the YAGNI kind of idea says, let's just deliver little pieces of it at a time. And if the first story only needs this part of the database layer then let's just do that piece of database layer and then the next story might need some more. And use some of the first part and do that and keep the system clean and in good shape as we go. And evolve those pieces rather than having to pay for the whole thing upfront. And you have to build some skill in doing things in an evolutionary way but what it gives you is you haven't spend a lot of effort on things that you don't really need yet. And like so many other things, we're not so good at guessing and a lot of times we kind of spin up a very elaborate solution and then when it comes down to it, it really is over kill for what we are doing and if we did it in small bites we would realize it shouldn't been that hard. And all the time that we would have spend on that, we can now take out of our development and apply it to something else so we're hoping to come out ahead. Once in a while we might guess wrong and we need the elaborate structure, but we've save that time for that because of all the times we've save time. >> And why do we need to have this discussion at all? Where do you think the tendency to want to build a more elaborate construction then might be necessary, where do you think that comes from? >> I think partly it's training, I think a lot of people have been trained to think that way in terms of designing some complete thing. And I think there's sometimes a sense of like I'll be more efficient if I just focus on this and get this all done now while I'm in here. But that only kind of works if you're always consistently right about things. And I don't know, I feel like I'm smart enough and I'm wrong often enough when I'm paying attention. >> [LAUGH] >> To whether I was right or wrong. So it's like, I'm willing to take the more small bite thing because of that. But it's definitely a natural tendency to think, I want to just own this beast and get it done. >> And is there attention between thoughtful software architectures and doing things in small bits at a time. Can you get both of those things if you play your cards right? >> Well, I think you can get a lot of it, I'm not sure you can say I never need to do any architectural thinking upfront or anything like that. But I think if you kind of structure things to learn early on, I think the advantage you have is if the stories your working on first are the critical ones for the system. And almost always those are the ones that are critical for the architecture of the system and credit card processor and we're processing credit card transactions. That's the thing that happens millions of times a day and I know from my system, I've got to be able to tolerate that. Some story like that is going to come to pretty early on, it gives me an opportunity to say like let's explore the performance aspects of this. And the scalability and other kind of non functional things we need and make sure we're growing in a way that supports that but it also lets me just focus, get the earliest pieces going and and let them go. So the priority we get from those early ones can help drive what the key drivers and the architecture, as well. >> Let's talk a little bit about how this works with the individual. I mean, you're working with a team and a developer says, Bill, I don't know about this YAGNI thing I've read about it, it sounds okay in theory, but, well, I'm not sure if this is the right idea, Bill. How do I know if this is the right thing for me? And how am I going to see it working if I actually try it? I think it's one of those things I like to encourage teams to try experiments. And take things, so even I guess my, I say trick, I'd say technique but one of my techniques is to say you may disagree that this'll work for you but it could still be in your favor to run the experiment. Because we run the experiment and it comes out the way you think it's going to, you won't have to hear about it for months and months because the team will agree. Yeah, we tried it, it didn't work. So try the experiment even if you don't think it's going to work. If it feels like there's a chance and the team's behind it. Either way you can support the experiment and fine some peace and learn whether it's going to help you or not. You don't have to jump into everything all at once, but I think a lot of times you can try and find those pieces, and the reality is if a system's going to last for multiple years, it's going to have version one, version two, version three, or 1.1, 1.2, so on, and every one of those is evolutionary version of your system. We're just speeding up the air holes on that and trying to take advantage of that in a smaller scale. >> That's great. That's some really practical advice on how to think about approaching agile from a development standpoint. Thanks, Billl. >> Sure. Thanks.
