JOE:
I've been doing Agile for like 12 years now and I'm very opinionated about it.
CHUCK: [Laughs] Good!
AJ: Well, I’ll just listen to you and make snarky comments along the way.
[This episode is sponsored by ComponentOne, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com can check them out.]
[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net.]
CHUCK: Hey everybody and welcome to episode 18 of the JavaScript Jabber show. This week on our panel, we have AJ O'Neal.
AJ: Coming at you live from space.
CHUCK: We also have Jamison Dance.
JAMISON: Provo, Utah -less exciting than space, but still exciting.
CHUCK: And Joe Eames.
JOE: Utah as well. Somewhere in the desert of Utah.
CHUCK: [Chuckles] Somewhere in the deserts of Utah. I'm Charles Max Wood from devchat.tv. You may notice that’s a little bit different. I'm going to have that website up this week and I'm going to start moving all the podcast over to it so then you can follow everything that’s going on over there. The site is up, it’s just not complete. So you can go and look at it and see how pretty it is but that’s about all you can get at this point. Anyway, let’s go ahead and jump in talk about Agile development. What is you guys’ experience in Agile development? What methodologies have you used and have you worked at many places that follow an Agile methodology or try to adopt Agile in some way?
JAMISON: So I'll go first since I'm probably the least experienced of it. I feel like I'm kind of… iTV is kind of a post Agile place. We've tried Agile stuff and for lots of rapid prototyping, without well-defined specific features, it kind of struggles a little bit. So, we did like points and it was kind of a Kanban type thing where we had a board and we have then cards and moved them around and stuff. But we are lot less formal now. It wasn’t a good fit for us. And I don’t know if that was because we were doing it wrong or because of the way that we work and what we are working on. It was probably several months of that and then it kind of ended a little bit after I got here. Maybe I destroyed it. Oh wow, never thought about that.
CHUCK: Agile wrecker, huh?
JAMISON: Yeah. I think I wasn’t Agile enough.
CHUCK: What about you, AJ?
AJ: I have pretty little experience too. Like we have done a lot of different things that I guess fit into the “Agile” buzzword like we've done stand up meetings, we've done scrummy the little post it note website. We've done a bunch of different things, but it’s just like the work flow changes from being something that’s intensely urgent, to then being stuff that doesn’t have like a secure deadline. And I don’t know, it’s just been really hard to find a good work flow, so I'm interested to hear more about Joe’s experience.
CHUCK: Okay. Joe?
JOE: Well, I think it was 2001 when my company transferred its practices to Scrum and we went to a training process. And every company I've worked at since then has practiced some form of Agile, pretty much some variations of scrum. Some of them more Kanban, less Kanban than others, so I've been doing Agile now for 12 years -- almost 12 years -- and basic math skills escape me, I guess that’ll be 11 years. So I've seen a lot of different incarnations; big companies, small companies. And the companies that I go to or interview with that Agile is a requirement for me, which kind of back with something that Jamison was talking about over at iTV where some I'm familiar with iTV how they operate. And I would say that they are doing Agile, they are just doing their own flavor of Agile.
CHUCK: Interesting. So, I worked at a couple of places where we practiced various forms of Agile. I worked at one company where I was the team lead and the process was pretty much when I got there, the CEO wants just go do it and it moved pretty quickly from that into more of an Agile setup, but a lot of that was because I could push it that way. And then when I left there, I went to Public Engines crimereports.com. And when I was working there, we were… they were kind of in Flex, like they kept changing the methodology that they were using and didn’t really adopt a lot of Agile processes, but I was there and a friend of mine David Brady was there and so we started kind of leaning on things to try and get things into an Agile methodology. And in the process, we convinced our boss to not only let us go to Agile Roots -- which is a local conference in Salt Lake City. I'll put a link in the show notes. I think this weekend. And I've got a ton of stuff going on this weekend so I
am not going to be able to make it, but I wish I could. So anyway, so we convinced our boss to let us go and then he decided, “Well, heck its right up the street,” because it literally was like half a mile away on the same road that our office was on, so we convinced my boss to go with us and to bring the entire team. And so we all spent two days there and when we came back, he was totally on board and so we started adopting all of the Agile stuff.
AJ: So real quick, why don’t you just go ahead and give us a definition of what Agile means? Because as far as I understood it, it basically means instead of planning things out completely for three years and then working on it for five. If you get it wrong, you work on it a week at a time, right?
CHUCK: Okay. So the first thing I'm going to tell you is to go to agilemanifesto.org. This is the manifesto for Agile software development. And basically, here I'll just read it. It’s really short. It says, “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.” And so, I think if you are trying to boil it down to waterfall and not waterfall, I think you really miss a lot of the value that’s in Agile development. For me, the big value in Agile development is that you get to focus on these things. So I'll just go into these real briefly. I know Joe is going to have stuff to add, but I think the big thing is the first one, “Individuals and interactions over processes and tools.” The Agile processes really open up communication about what you are working on and why you are doing it, and I think when you miss out on some of that, you really do yourself a disservice; you wind up rebuilding things over and over again because they are not done right; you are not communicating with the people who are building pieces that are adjacent to yours. And so you really start to… you lose a lot of value when you are focused on the processes as opposed to focused communication. Do you have anything to add there, Joe?
JOE: No. that’s a great summation of that, I think.
CHUCK: So the other one is “working software over comprehensive documentation,” I think that's pretty self-explanatory. You wanna deliver stuff that works all the time, you know. So you don’t commit unless it is working, you focus on deliver things that work and do what they are supposed to do, it just… I don’t know what else to add to that.
JOE: So I don’t know how many of you guys have worked in environments where the documentation became was paramount. I spent a short stint at a government contractor many, many, many years ago and the reason it was a short stint was because of how they operated. And they told me, I actually wasn’t there for this part of phase of it, but they started out with 6 months or a year of just documenting the requirements of the system. And so they ended up with… I can’t remember how many thousands of pages of documentation about how the system that they were going to build was going to work, and it was an inventory system. And then when you are 8 months, 10 months, 12 months into it, the customer’s representative on their team was getting so tired of all this, they finally went to the branch of the government they were working for and said, “Hey we really need to start building the software.” And they finally said, “Okay.” So they take the documentation and they put it on the shelf and nobody ever opened up the documentation again. And they actually built, at that point, started building software that people wanted; not that they did a great job at it, but they realized right from the get go that all the documentation they have done was completely useless and that they were trying to build software that somebody actually wanted to use and could use. And so, for people that have never been on that situation, and especially on this day and age, where we frequently don’t see that, like we did back in the 90s -- even more so, 80s and really on -you don’t… it’s hard to comprehend what it was like when you would spend 6 months, 8 months, 12 months writing documentations. You spend more efforts on the documentation than on the software -- at least it seemed like.
CHUCK: Yeah. And I've also seen it where -- and this kind of leans more towards some of the methodologies than necessarily what it says in the manifesto -but I've seen teams basically get in and they have this development cycle where they build, build, build and then they have a big release after like 6 months or a year. And if you tried to use any of the build systems in the interim, they wouldn’t work. And so it’s the same; instead of documentation at that point, I mean they’re just totally missing the picture of “working software”. The other thing is that they do what Joe is talking about and they have this upfront, “This is what we are going to build.” And so they don’t look at what they are actually building for 6 months; they just crank it out and at the end of 6 months, they have released what they designed 6 months ago without ever getting any validation that that’s actually what they needed to build. And so, you wind up running halfway across the country and you find out that you went the wrong way -- it doesn’t go any good.
JOE: Yeah. I think a lot of people don’t realize the contribution that Agile has made to the software environment in ways that we haven’t noticed, that all the companies that are doing what they would consider to be Agile are still heavily influenced by the Agile movement. Companies, like I said, that do these 6 and 12 months of documentation before they build software, you just… nobody is doing that anymore because the industry as a whole has realized that was a bad thing. And that came about because of the Agile movement or at least it was documentation… -- not documenting, that’s a bad word. [Chuckles] -- but they encoded that knowledge, right? And said, “Hey documentation isn't really not that important.” And that word spread and now companies, they don’t do that even if they are like, as Jamison was talking about, “Oh we are not doing Agile methodology because we are not doing any recognized Agile method.” Still, they have not fallen back into the old bad habits that we had in the 80s and the 90s as an industry.
JAMISON: So, I just wanted to say a couple of things; I came to software development in the post-Agile world, so I think a lot of the things I just take for granted, the way you do things, it’s not Agile. It’s like how you develop software. It doesn't have a name. It’s just what you do. So I agree with Joe that lots of this is a product of Agile coming about and it’s kind of weird that it wasn’t always this way. It just seems like the way you do stuff. But I also wanted to ask about the difference between the Agile, the manifesto and the Agile the product, because there are lots of people making lots of money off of the word Agile. And there's all kinds of… and I think it’s funny because the manifesto says like people all over process or whatever is that what it says? And then there are all these… you can go out and spend tons of money on Agile tools, you know? Like, I don’t know. So how do you differentiate between things that are actually Agile and things that are like built around the buzzword Agile.
CHUCK: I'll let Joe jump in to this first. I have huge opinions on this, but…
JOE: Well, I certainly have something that I often joked about co-workers about we value the interaction over the tools and that there's so many tools out there, but on the other hand, when you try to do. But if you try to do Agile, especially in a remote team, those tools are very enabling, right? So whether you are using physical artifacts, you know, white boards or Kanban boards, whatever, sticky notes up on everywhere, plastered everywhere or using virtual, the tools are definitely enabling piece. So I think they have a lot of value. I've used a lot of different tools for Agile of different kinds. And I've seen a lot of value out of them but you definitely have to realize that it’s not the tool that makes the process; it’s not even the process that makes Agile what it is. It’s not the tools that make Agile what it is; it’s what you guys do as a development team and not just as a development team, just developers but as an entire product team. It’s what you guys do and how you build your software that’s what makes Agile, Agile; not the tools you are using. There's a great quote in some video – and I wish I could find a
link -- where there's two people talking and one guy says to the other guy, “Do you do Agile?” He says, “Yes we do Agile. We do the Scrums, right?” [Laughter]
CHUCK: Yeah. “We have stand up meetings, so we were Agile.” So yeah, so my take is pretty much along the same lines. The way that I see it is that you have Agile principles are kind of the core values that guide software development, if you are going to follow Agile or whatever – an Agile process I guess. Then you have all of these tools and methodologies and people trying to tell you on all these different things. And ultimately, what you need to do is you need to find the tools that facilitate these things, that make it easier. So these aren’t software tools, these aren’t tools that let you build software, they are tools that help you make it easier for individuals and interactions to do what they need to do. So they make the individual’s job easier, they make the interactions occur, they make the interactions clearer. You have continuous integrations that allows you to focus on working software. You know, you have different project management tools that not only help you manage and define the interactions between the team members and the different pieces that they are working on, but allow the customers to come in and say, “This is what I want.” “This is not what I want.” And so, they are Agile tools in the sense that they help make this job easier; they support these principles. And if they don’t support the principles, then they are not the right kind of Agile tools for you. And so, for example, there are some project management tools out there. I don’t necessarily wanna pick on them, but they are the big names in Agile project management tools, and I can’t stand them. And the reason is because they are so complicated, that you wind up going back over to the right side of these things, where it says, “the things on the left have more value than the things on the right”, where you spend more time fiddling with your tool than you actually spend interacting with the members of your team and communicating through the tool.
AJ: That’s why your team has to build the tool.
CHUCK: [Laughs] Yeah, now we are going to get into “not invented here”, right?
JAMISON: So that’s another thing. The Agile manifesto doesn’t talk about the other Agile like “not invented here” or “you ain't going to need it” or DRY. So there's a bunch of other stuff as well. It just seems like pragmatic… not necessarily.
AJ: That’s because Ruby didn’t exist yet. [Laughter]
CHUCK: I think a lot of these conversations took place before Ruby was around. I think the Ruby community adopted a lot of them, maybe a little more vocally within the community than some of the other communities out there. But I don’t think these conversations are necessarily even unique to Ruby. But ultimately, again it comes back to DRY; again, you can feed it back in here. It doesn’t add directly to the conversation about working software, but ultimately, it is a principle that helps you get working software, maintain it -- and so it important. But ultimately, you are trying to figure out how you can make these things occur. You are trying to figure out what you can put in place to help facilitate these interactions. What you can do to make sure your software is working, what you can do to get your customer more involved and have them collaborating with you. And then, you know, make sure that you are adopting changes that you see. And so you’ll see a lot of different methodologies that bring in these ideas that tell you, “Okay, so you should be having scrum every morning.” Why? Well, it’s not so that you can stand up and beat your chest and say, “This is what I did.” It’s so you can stand up and if you have a problem, you can ask if you wanna let people know that they can move ahead and connect to something that you can just build, then you do that. But you know, it’s about interactions, it’s about the communication. If you are having retrospective, you sit down and you say, “Okay, this is what we've been doing. These are some of the things that we tried out,” which is built in to just about every methodology I've seen is where you actually sit down and talk about the methodology, you say, “We are going to try this new thing for a week or two or three or ten,” or whatever, however long you think it’s going to take to really get it and then you sit down and you start talking about it. Well, when we do pair programming, we've noticed that it works really well under these circumstances and not so well under these circumstances. And then you adapt so that your process becomes better and better suited to what you are doing -- and that’s what Agile is about. So you know, ultimately, whether or not you are going to have… (man, this is a long rant) so whether or not you are following an exact methodology or whether you are picking up pieces from extreme programming and pieces from Scrum and pieces from Kanban and pieces from somewhere else and something else that you read about on the web, you know, ultimately, you are looking for something that will allow you to do these things correctly so that you could build better software.
JOE: That’s a great way to sum that up.
CHUCK: But the tools are just that. They are just tools. They are just things that make it easier for you to get there.
JAMISON: So we are on the JavaScript Jabber podcast; how does Agile relate directly to JavaScript? Is it just that someone needs to make Pivotal Tracker in JavaScript and relates to JavaScript or…
CHUCK: [Laughs]
JOE: My own personal take on the relationship of JavaScript and the need for Agile in JavaScript development kind of comes down to the whole… maybe this doesn’t necessarily apply as much if you’re a Node developer and you are developing in Node but if you are a browser developer, you are doing JavaScript in the browser, the whole point of doing JavaScript in the browser is because you are enhancing the user experience, right? If you weren’t trying to enhance user experience, it’s probably quicker to build things using a server-side language than it is to build them using JavaScript. But what you are getting out of JavaScript is a better browser experience for your users. So that goes back to this “whole working software customer collaboration responding to change,” all those principles of Agile, that's what JavaScript is delivering to the industry as a whole. JavaScript is bringing an enhanced user experience to the industry, quicker delivery over the web. And so, Agile is… JavaScript I think is a way to take those Agile principles and just keep applying them and keep iterating as an industry so that we are creating better software. So they don’t directly relate, but the principals involved in doing JavaScript development and enhancing that user experience is kind of what Agile manifesto is all about is actually delivering software people want not delivering software they don’t want.
JAMISON: So you talked about how it applies a lot to the browser if you are doing UI stuff because that’s the thing that the end users are using. I think it applies just as much to internal services or backend services that maybe someone else in the company is consuming. We have lots of small teams that are working on different services and our customers are the other people on the engineering team. So we still have to have communication with our customers, we have to iterate quickly and build stuff that they actually need and still apply those principles, even though our user base is a lot smaller and a lot more specific. They’re probably a lot more understanding of technical problems though, so there are differences for sure, but I think it definitely applies when you are doing backend server side stuff as well.
CHUCK: Well of course it does. I think what Joe’s point is that with the browser thing, you are directly facing non-technical customers most of the time, and the other thing is that the feedback loop can be so tight because all you really have to do is make your change and then tell them to go load it in their browser again. And so, you really get that quick iteration and fast customer feedback. And it’s really easy to communicate it as well because ultimately, you can just show it. So you know, that makes a lot of sense. Is there anything else we wanna add before we start talking about methodologies?
AJ: I have a question, I guess. I don’t know if this would fit in, but the whole idea of to do something right, you’ve got to write it three times. Does that fit into this conversation at all?
JOE: If I have to write it four times, does that make me dumber than everybody else?
CHUCK: [Laughs]
JAMISON: You got it, writer. [Laughter]
CHUCK: We all knew you were special, Joe. So, again… I keep jumping in. I have an opinion on all of these things, so one part of…
JAMISON: You might say, you are really “Agile” -- able to jump in quickly.
CHUCK: Yeah. I know Joe will have an opinion with this too because I'm going to talk about TDD, but basically, building it right the first time, a lot of times does mean writing it and then rewriting it. So for example… TDD’s mantra is “Red, Green, Refactor”. And I know a lot of TDDist that do red, green move on. And ultimately, if you do the red green refactor -- and this is something that came up when we had Kent Beck on Ruby Rogues, he was talking about how code is meant to communicate with the next person is going to have to come along and change a code, or make it do something else -- and that’s really where that comes in is Red Green Refactor. So if you can consider that your code is an interaction with the developers in the future -- even with yourself in the future -- then Agile applies directly to it. Because again, that's that first principle; individuals interactions over tools and what was it… processes and tools? And you know, so your code is actually an interaction and not just with the machine. And so if you have to write it 3 or 4 times to get it right, then that’s fine, as long as it’s in that refactor phase. If you have to write it 3 or 4 times to make your customer happy with it, then you need to start looking at how you are interacting with your customer and how they are collaborating. Because ultimately, you should be able to get pretty close to what they want from what they are telling you, and if not, then again that's when you come back; you review your process and you’ll see where you’re going to go. But if you have to write it 3 or 4 times to make it work, I don’t see a problem with that.
JOE: So, I have a different take on what the statement, “you have to write it 3 times to get right.” To me that's applying to the iterative process of building software. Which iterative development isn't unique to Agile; you can do an iterative waterfall process, just do a whole bunch of small waterfalls and still be doing iterative development and still improve your process.
CHUCK: It feels like you'd hit the rocks three times though.
JOE: Yeah exactly.
CHUCK: On the way out.
JOE: But if you are iterating… it seems like the projects that I've been out that works the best are often the ones that didn’t end up at all, like the first version of the product that we show to the customer was like, the customer was giving a feedback and saying, “Well, I want it to be this way.” And then you change it, you put that next version and they see it and like, “Oh, I actually want it differently.” And so then you change it again. And then they start using it and then they realize as they are using it, they really wanted it in an entirely different way. And so that “you will write it three times to get it right” statement I think really applies to Agile development or iterative development as a whole because your iterations should actually cause you to write your software multiple times. I'm very surprised if I end up rewriting every line of code that I've written at some point more than once.
CHUCK: That’s because you do learn lessons as you go.
JOE: Right.
CHUCK: And another thing that’s kind of interesting about that is have any of you done a big rewrite, like the major rewrite of your entire application on anything?
JAMISON: Sort of.
AJ: Everything.
CHUCK: So I've done that a few times and have you ever noticed that you tend to do things maybe a little bit more intelligently and a little more the second or third time? And I think that’s another illustration of this point, where you figure out this kind of thing didn’t really work last time or I had to work around it this way this time, so maybe I'll try it this way this time in order to make it go. And it’s the same kind of thing where you iterate over in this case, your entire application.
JAMISON: So I think that idea of embracing the fact that you might have to redo stuff or I think it’s just acknowledging that you’re fallible and you are not omnipotent and don’t know everything, when you do stuff, of course you are going to learn better ways to do it, and you might not know where the pain points will be until you try to do them. And so I think that’s where the value in rewriting stuff comes from because you’ve already done it once, you already know what sucks about it and so you can fix it. I mean if you can get away without having to rewrite it, then that's obviously better. But if you do need to rewrite it, and of course it’s going to be better because you learn stuff and that’s because you didn’t know already.
CHUCK: Absolutely.
JAMISON: Now I'm an Agile consultant. That will be $10,000. [Laughter]
CHUCK: I know a few of those. [Laughter] And it’s funny too because you meet some of these folks that are Agile consultants, they go out and they help make teams make the transition to the Agile development. And it really… they’re really usually very personable people; they explain things really well and it’s almost like they kind of have the Agile manifesto in the way that they approach the teams. And so, you know, they are iterative and you know, value the individuals on the team over the processes. And all of the things that we are talking about, they apply it to the team. And I
think it’s really interesting to see that Agile principles apply to much more than just the software.
JAMISON: So you practice Agile parenting with your children?
CHUCK: [Laughs] Only before I lose my temper.
JAMISON: …the scrum master and they’ll have different connotations. You'll be like cracking the whip standing over them.
JOE: I know a lot of companies that I've seen; they’d practiced Agile outside of their software department as well as inside of the software department.
CHUCK: Yeah. It kind for brings me to the Lean StartUp, Eric Ries. Are you guys familiar with his stuff at all?
JAMISON: I’ve heard about it. I haven't read it. I've heard people who have read it, so that doesn’t really count.
CHUCK: So the principles are a lot the same where basically, you do a lot of customer development, make sure you understand what people want and then you get a minimum viable product, which is just the minimum thing that you could possibly build that people would want and want to buy and then you start that feedback. So then you start getting that information back from the customers about what they want and you iteratively, basically build what they want. And it’s kind of an interesting approach, but yeah, you get these business practices that are effectively based on Agile development.
JOE: Yeah that concept of minimum viable product is definitely one of those ones that should be already phrase in the mind of every Agile developer; getting that product out to the person as quickly as possible -- from a software development standpoint of course, that's what we focus on -- but we want our businesses to have our same goal in mind, because if business doesn’t have that goal in mind, it definitely is harder for the engineering team to have that… to do that. I was at a recent company who spent three years before they put their initial version in front of any external customer and the initial deployment just horrible. They had no idea what resolutions the customers are going to be using and they designed a whole entire application around high resolutions and not realizing that their customers where going to be using a lot of the small resolutions on the machines because they'd never bothered to put it in front of the external, real user. The business didn’t want to; they didn’t want to expose those customers. They were worried; “Ooh we don’t wanna expose the product.”
CHUCK: Yeah that's the approach that I took when I was… I had some suspicions that I was diabetic and so I avoided going to the doctor because I didn’t want to know. That's how many problems that solved. Because it’s the same thing, right? We don’t want to know that this is failing. No, you want to know that its failing right up front. And you know, a lot of the Agile stuff is based around that. That’s why you're getting the customer involved from the beginning is so that you can figure out that what you are building is the right thing, two days in instead of two months in, because its expensive to pay developers for two months. You wanna write the right code. It could be beautiful code, but if it doesn't do the right thing, it’s useless.
JOE: And that has nothing to do with flavor of Agile you are following or if you are following something you didn’t even think is a flavor of Agile, it still follows the same principles.
CHUCK: Yeah absolutely. So what methodologies have you guys used? We mentioned Kanban and Scrum; are there any others that you guys have tried?
JAMISON: Oh wow, is that how you pronounce it? I sounded like an idiot every time I’ve said that word.
CHUCK: I’ve heard “kænbæn” and “kahn-bahn”. So, I don’t know.
JOE: Yeah they are on the wiki article I believe. They have a pronunciation guide and they say Kanban is okay, Kanban is okay and I think they say Kanban, is okay but not Kanban. I can’t remember. One of the two was not acceptable. Three of the four are acceptable.
CHUCK: One of these things is not like the other.
JOE: Yeah.
CHUCK: That’s funny.
AJ: It’s my favorite song.
JOE: So I've only done Scrum, Kanban and then just various flavors. You know, personal flavors of those two.
CHUCK: Yeah, I'm pretty much in the same boat, though I have done basically Scrum that borrowed things from XP like programming. XP is Extreme Programing for the unfamiliar.
JOE: Isn't XP just like a rumor? You know, it’s like a myth?
JAMISON: [Chuckles]
JOE: I never met anybody who's done XP.
JAMISON: Can you talk about the difference between XP and Agile? Because it’s kind of fuzzy to me.
CHUCK: So extreme programming is…
JAMISON: Is XP like swords?
CHUCK: Okay. [Laughter] swords. There you go.
JAMISON: Extreme.
CHUCK: Yeah. And extreme programming is when you put poison at the end of the swords.
JAMISON: [Chuckles]
CHUCK: So basically, what you are asking in my mind is what is the different between Agile programming or Agile development and Agile methodologies. Because I think there's kind of a spectrum there. So the Agile development or Agile software development is basically an endeavor to follow these principles in order to write great software. Agile methodologies are a set of practices that are designed to make it easier to achieve the highest level of Agile software development. And so, you get a collection of things that you do that are supposed to make it so that it’s you effectively are being more communicative, that you have the customer involved and things like that. So they give you sometimes rigid practices to follow. So Extreme Programming, I don’t know all of the… but you know, the one that a lot of people talk about is pair programming, but they also TDD, they have some pretty rigid rules for getting your customer representative involved and what their role is and you know, they have some pretty heavily defined roles that different people play in order to represent each of the different pieces that need to be in place in order for you to effectively benefit from the principles of Agile software development.
JAMISON: So, its processes and tools and a plan to help you value individuals and interactions over processes and tools?
CHUCK: I know. It sounds kind of backwards, doesn’t it?
JAMISON: Okay.
CHUCK: But effectively, yes. I think there has to be some level of organization though. You can’t be Agile just by winging it. I think you have to have some idea of how you are going to implement and facilitate different principles there. So you know, while it sounds kind of funny to say that you are going to have a plan, I think you need one.
JOE: Yeah. And you know XP I believe was the very first flavor of Agile. Scrum came shortly after that. Then XP they were really trying at that point to really change the face of development. And lot of problems that are being encountered at that point that Agile was meant to solve where things that XP specifically tried to overcome, askew, get rid of. So very little documentation, a customer collaboration they had these roles defined for the customers to be on board and be around the development team all the time.
And they have very specific names and when you go and do estimations, they actually have this very… they call it the game and the customers and the engineering team play this game in order to estimate all the pieces that are going to be built in the next sprint and that’s very prescribed. Scrum isn't really any different. If you look at the difference between Scrum and XP, besides the fact that you are not doing necessarily don’t have to be doing pair programming, it’s a lot of the same stuff; they just put different names on it.
CHUCK: Yeah and sometimes the order or structure is a little bit different, but yeah you are doing a lot of the same things; you might just be doing at different time or different place, but yeah. You know, with Scrum, you have the Scrum master. And I don’t remember what the role is in XP, but yeah, it’s basically the same thing and you are doing a lot of it. I really do like a lot of the processes just because it open things up and allows you to really kind of explore where you wanna go. And there are a lot of people out there that will tell you that if you are not following every little thing that extreme programming prescribes and you are not doing extreme programming. But ultimately, I think if you adopt extreme programming and then you take more of a measured approach to it, saying, “Okay, this is working.” “This isn't work.” And start doing the retroactively saying, “Okay we are going to try and adapt it this way to see if this will work better for us.” And eventually figuring out what works best for your team, I think you'll get more out of it than just doing straight strict extreme programming.
JOE: It seems like the Scrum practitioners are more tolerant of that attitude.
CHUCK: Yes.
JOE: Again, like I said, I think XP practitioners are unicorns; I don’t know if they exist at all, [chuckles] but it seems like Scrum…
JAMISON: And if they do, they stab you with their horn.
JOE: Like unicorns do. But it seems like Scrum kind of develop as people saw the way that XP work. But it seems a little extreme – no pun intended – and so, you know, let’s do something that is following most of the same things but let’s soften it up a little bit; make it easier for companies to adopt these practices. And so scrum… and I think I've seen them in a lot of places, the wide spread feeling of practitioners is you doing Agile, whether you're doing every exact thing that’s involved, even in Scrum, you can stills say, “We are doing our version of Scrum.” And a lot of the books will tell you that you should be changing the practice to fit your organizations. So if one piece doesn’t work, then do something different.
CHUCK: Yeah. The only other thing that I would add in here -- and this is going to be a little bit controversial -- but that is if you are setting things up so that you can follow a methodology, whether its Scrum or something like Scrum or XP or whatever, if you find – and I've seen this on teams – if you find that the adoption is working really well, the team is really gelling, except for that one guy, then your problem may not be your process; your problem maybe that one guy and its okay to let him go, honestly. Because having that level of collaboration and cooperation and having everybody on board is worth way more than even in expert in whatever field you working in. And one other thing that I wanna jump in and talk about is just the people who are making the transition. Now, most of the people I’ve sees making the transition from something to Agile, they transitioning from, “We don’t have any idea what the heck we are doing and we don’t really have a process,” into Agile. I very rarely see anybody have a rigid waterfall methodology anymore that they are trying to follow and then realize, “Oh gee, we should do Agile because it gives us these benefits.”
JOE: Yeah. I think in this day and age, what most commonly happens is that people are practicing methodology that they don’t really call a methodology, but it’s what they do and they actually have prescribed methods and things, practices that they follow, and they are really all very inspired by Agile because they are developers, whatever, just to reading or have been to places or doing a lot of the same things that Agile does, but they are not really doing a very easily recognized form of Agile. And so, then they try to become a little bit more formal in an attempt to make the development go a little bit better.
CHUCK: Yeah. My experience has been both. I've seen it where they have a lot of more rigid policies around different things that are more reminiscent of waterfall, where you have these major change requests and these huge big upfront designs that are being done behind closed doors that kind of get dropped on the development team when they are ready. And so then they have a novel to go through and then implement. And you know, they realize that they could get more from their developers if they adopted more of an Agile standpoint, but most of the time its more along the lines of what Joe explained. And they are somewhere along the continuum of waterfall in Agile and making that transition. But making the transition is hard. And what ultimately you have to do in order to make that transition is you in my opinion, the only way I've seen it worked is when the whole team adopts the whole methodology. And then from there, you can iterate from that starting point. But you have to adopt the entire methodology and do it at least for a
month, so that you have an idea of what is going on and when you are headed and what's going to work for you and what isn't. Because if you are not doing that, if you don’t do it for at least a month, then you'll miss a lot of these things and you will run into resistance. And that month is just enough time to get over the resistance and really see the benefits of what you’re trying to do. If you don’t, then you may find resistance on something that will ultimately benefit you once you get used to it. JOE: Absolutely. A big failure point for companies adopting Agile is just the lack of a full commitment to it.
CHUCK: Yeah.
JAMISON: So I just wanted to say one last thing; I made some disparaging remarks about XP. I was joking, I haven’t really done it, so I can’t have a real opinion about it. But I think the idea, the main idea behind Agile seems to me to be that there could be better ways to do stuff than what we are doing. And it proposes some specific ways that they think are better, just that idea that you can improve this process, I think that’s very valuable. And I think that doesn’t have to end with, “Okay, we did the things on Agile manifesto, so we are done.” Or “We did the things on the XP list, so we've improved it and we are done.” I think you can always find better stuff. And that means you will find worse stuff too, if you try stuff and it doesn’t work, at least you know now.
JOE: Some of the worst development I've seen was following a very easily recognizable Scrum process but parts of the principles underneath that they were missing, you know, they weren’t following the manifestos as much as they are following Scrum practices.
CHUCK: Yeah. The other thing is that in a lot of cases… oh, my mind totally went blank. [Chuckles]
JAMISON: You can be Agile about your implementation of Agile stuff, right? If you are valuing the results over the actual process of Agile development, then you can be like meta-Agile, you know? I don’t know. I think there's value in that.
CHUCK: Well, yeah that’s what I was going to jump in and say is that you need to be doing your retrospectives which is another meaning but ultimately, what it is you sit down and you talk about your process and then you figure out the pieces that you want to… you know, experiment with or the pieces that don’t seem to be working well and so you'll say, “Okay we are going to try this for this week.” And then you go back and you have a retrospective on it and say, ”This worked well for us for this.” “This worked well for… this didn’t work well for us.” You know, figure out why; see if there is a better way. And you know, ultimately, doing that having that practice is just really important for iteratively figuring out what works for you in your Agile practice and then moving ahead with it.
JOE: Yeah, absolutely.
CHUCK: Anyway, I think a few of us need to wrap this up right around 11, so I'm going to go head and jump in and get us into the picks. Joe, why don’t you start us off with the picks this week?
JOE: Okay. Cool. So, because we are talking about Agile, I wanted to pick a DHH’s book, Rework. I thought that that was a pretty good book and a lot of Agile principles involved in it. And on the same note, James Shore went to a kick starter project and put together this Let’s Code TDD Project that will be released sometime in July, where he is recording and screen casting himself just writing a project using TDD but its JavaScript. So that’s going to be very interesting. That’s my second pick. My third pick is a book called Resurrection, which is an Amazon eBook. I don’t think it’s available in print, but it’s only a couple of bucks. Sci-Fi novel, very cool book. So if you are looking for a good Sci-Fi read and you have a good e-reader, Resurrection.
CHUCK: Awesome. AJ, what are your picks?
JAMISON: Microphone.
CHUCK: Mute button.
AJ: Oh, thank you. That’s right. The mute button. My shave this morning, best shave of my life. So, I got this Merkur Double Edged Razor. I imagine talking about this before one time, did I? Or no?
JAMISON: No.
CHUCK: Double edged razor, that sounds like a sword in miniature.
AJ: Yeah it’s kind of like that, except not really at all.
CHUCK: [Laughs]
AJ: It’s just like the old school kind of razor that your grandpa would have used or something and I got this kit off of Amazon that has a razor and a brush and some shave soap and then like 10 different brands of blades, so that I could try them all and figure out like which one works best.
CHUCK: I have to ask, if it’s something my grandfather would have used, it’s that something you strop on leather before you use it?
JAMISON: Those are the single edged ones.
CHUCK: Oh, yeah. Sorry.
AJ: Yeah. It’s not the straight razor. It’s the safety razor. Of course the real men, they don’t wanna call it a safety razor, so they call it the double edged razor.
CHUCK: [Laughs]
JAMISON: A danger razor.
AJ: But the first time I used it, I cut myself up pretty good and then I watched this video on YouTube of this guy in Vegas that’s showing his brother or somebody how to shave. He's like, “I promised you when you go to Vegas, I was going to show you how to shave, it’s like so.”
CHUCK: [Laughs]
AJ: But he's got a good technique and so I started doing that and this morning was the first morning where I got like baby smooth soft skin and no nicks. So I’m finally starting to master the skill of it. I love it.
JAMISON: I’ll have to look at that because I bought a double edged razor. It wasn’t one of these fancy ones like you have. It’s quite cheaper but I had a horrible experience, so maybe I'll try this and do this again.
AJ: Well you got to shave with the grain the first go. That’s really important. You can’t shave against the grain at all. So if you got one of those little curly patches where your hair swirls around, you just…
JAMISON: I got like a hundred of those. Each of my hair like points in a different direction.
AJ: So I have that problem on my neck, I don’t have it on my face so much, but on my neck I have that problem, but it’s just you got to pay attention, you got to make sure that you go with the grain. And then on the second pass, then you can go kind of sideways, you never wanna go against it because you don’t need to go against it to get like baby soft. You just need to go like sideways like a 45 degree angle from the grain and you do that.
CHUCK: Yeah next time I see AJ, he is going to have a four o’clock shadow.
JAMISON: [Laughs] Well, if I'm not here next time, it’s because I slit my throat on accident.
CHUCK: [Laughs] Watch the video, then you'll be an expert.
JAMISON: The danger razor got me.
CHUCK: All right. Jamison, what are your picks?
JAMISON: I'm going to go with four picks. The first one is XCom Enemy Unknown. It’s a really old strategy game. The old game was amazing too, it came out 1993, but there is a remake that I saw some stuff at E3 about and it looks so good. The original one was part of my childhood and this one will be part of my adulthood. You basically build up this base with these army of guys and then you send them out to fight aliens in little missions and you develop really… at least I developed relationships with the guys that I send out, you know, that I like them and then get personalities for them and then they all die and you feel really bad because it’s like the farmer who you recruited who got shot by an alien and some nameless goon you are commanding. But that’s great. The next one is a website called 12factor.net and it’s all about how to build good service oriented apps. So how to build great services basically. We are doing a lot of services at iTV and we are running into some of the pain points of doing it, so this has been a really good resource for us to improve its stuff. I think it’s by some people behind Heroku because they wing to a lot of Heroku articles and talked about Heroku a little bit. It’s not like how to deploy to Heroku, its more general. But it looks like a great resource and it’s really helped us. And the next one is the website called nodemanual.org, if you've ever been frustrated by browsing the Node docs, this is another good solution. The thing I picked last week, Dash, it went to $30 instead of free like as soon as I picked it so, I'm going to unpick that and pick nodemanual.org. It also has a bunch of tutorials on Node, so it’s like docs + guide to Node kind of, so it’s been pretty sweet. And the last one is a good domain name service, iwantmyname.com. I've been doing stuff for a client that uses GoDaddy and it’s like being stabbed by like thousand foot long sword. You just like keep getting stabbed forever. And then I bought some domains for myself on iwantmyname.com and it’s been like getting little hugs from angels. It’s so much better. It’s really simple, really cheap, not spammy, really easy to use. It’s everything that GoDaddy is not.
AJ: Have you tried name.com?
JAMISON: I have not tried name.com, no.
AJ: That’s a really nice one too; very clean. And then of course Google’s is nice and they give you free privacy.
JAMISON: Wait, what? You can buy domains through Google?
AJ: Yeah they don’t really advertise it, but if you just type in Google register domain, it is the first link and yeah.
JAMISON: I don’t know if I want them owning more of my digital life than they already do, though.
CHUCK: [Laughs] Yeah. They own like all of my digital life.
JAMISON: Yeah. I'll look into it.
AJ: Well, it’s nice because you get Google apps set up like from the get-go you know, like Gmail and all that. And then of course you don’t have to use Google sites. I recommend that you don’t because there's nothing you can do with it, like there's no scripting capabilities or anything; it’s just like static files and they are not even files, they can’t even access to files, so that’s terrible.
CHUCK: Yeah you are signing up for pain if you are signing up for Google sites. My kid’s charter school uses Google sites for their website and I've gotten pretty involved with the governing board for the school and I keep complaining to them about the website. And they are like, “Yeah we are planning on putting on something else.” And I'm just looking at them like, “Yeah anything else, please!” [Chuckles]
AJ: But you don’t have to go with that. I mean I just wanna make that clear. I don’t use Google sites for any other stuff, but I buy a lot of my domains through Google because it’s cheap and they give you the privacy than most of the other ones charge like an extra $4-$5 for. CHUCK: Yeah. I've used GoDaddy for a long, long time and I finally am just totally fed up with them and So I've actually been switching my stuff over to hover.com and they are pretty cool. I actually need to get things worked out so that they can, they offer some kind of domain concierge service to move the stuff over and I just need to work things out with them to get it all moved out. So, anyway, I'll put them as one of my picks because I've been pretty happy with them, their DNS system on the backend is actually reasonable. [Chuckles] So they have that going for them as well. Anyway, so one other thing, since we are talking about razors, I'll go ahead and put a pick in as well. For father’s day, my wife got me an electric razor. I had an electric razor way back in the day when I was in college. Man, that’s been like 8 years or something since I graduate and it’s been longer than that, but it was a really, really, low quality one and I just didn’t like the quality of the shave I got out of it or anything. So anyway, with this one it’s been pretty nice. And so now I just grab it in the morning and spend 2 seconds shaving my face [Chuckles] and I've been really happy with it. And so I'll go ahead and put a link to that in the show notes as well. Yeah, I've had a lot of stuff going on lately. And I had a pick ready, I've totally just lost track of what it was because we were talking about all these other stuff, so maybe I'll pick it next week. But one thing I do want to do is thank everybody who replied to me on Twitter. I had a question about cross domain scripting with JavaScript and I’d look at a few options, but I wanted to make sure that I hadn’t missed any and I got a whole slew of responses from people. And so what I am working on is I am working on a
course on building JSON APIs, and by “course” I mean a two hour online training. You can actually go and check it out on buildingjsonapis.com. The site is a little bit of a work in progress, but you can go and sign up there. So I recommend that you go and do that and just let me know if you have any feedback on the site or any of the material that I've put up there regarding what the course and what it’s about. Other than that…
AJ: And one other thing, a request of our viewers. If anybody has ever done anything with tryruby.org or tryhaskell.org and knows how to manipulate that, I don’t even know what his online screen name is, Eric Jacobs just bought tryjavascript.org and he is changing his twitter account. He can’t settle on a name he wants to stick with and brand. But anyway, so if you tweet at me, which is @coolaj86 or jump on the Utah JavaScript mailing list, and you’ve got some ideas of what to put up on tryjavascript.org, we’d love to get something up other than my name [chuckles] which is what he put on there right now..
CHUCK: Yeah you can also tweet to @jsjabber, which is the Twitter account for the show and we'll make sure that those get through. All right. Well, that's it. We'll go ahead and end the show. We'll be on next week and we'll see you all then!