 Welcome to Agile Roots 2010, sponsored by Version 1, Raleigh Software, Virio, Amirisys, Agile Alliance, and Xmission Internet. Agile Development with Interns by Travis LeFure. My name is Travis LeFure. I'm here to share an experience we've had over the last year and a half with using interns in our development process. Through the slideshow you'll see that each time we have a batch we take a hydro. I have 15 years of experience in software development. The last six years I've been in management and I'm a huge proponent of Agile and what it does to help us accomplish our goals and provide value to our customers. Currently I work for Eugenius Technologies. I'm creating an emergent technology in the banking industry. It's called video banking. Basically you go up to an ATM, push a button and you can actually talk to a live teller and perform your transactions with that. Prior to that I worked for a company called In Contact, which is where this experience comes from and I've worked for them for the last six years. So I was given an opportunity with a local university called Dumont. They've been around for about four or five years and part of their curriculum is that you have to take two quarters of an internship. And in this internship, depending on how many credits you're going to do, you're going to do between four up to eight hours every day for a ten week period of time. And they have agreements with companies throughout the state of Utah and then several in California to take on between four to maybe sometimes up to ten interns at a time and put them on different projects. And so this challenge was interesting because how do we bring on board an entirely new team, train them, teach them, bring them up to speed so that they can be productive and give the company some value and at the same time get value back to those interns so that they can take something from that experience that would either enhance their skill set, make them more profitable when they go out looking for work or they can have some experiences that they can relate to and say, hey, I've done this, I've done that and they'll get a better starting position with where they go. And can you really get value out of a group of interns? You know, it's interesting, I saw the first batch and I said, man, those kids are out of high school, what are they doing here? You know, they look so young and what they're doing and they have a lot of energy and they're excited and they're just out there doing it, getting into the work but you got to focus them and help them to understand how teams work together understand the agile process and how to work together as a team. So my mission was to be able to take this group and help them to do that. The same concept that I'll be talking about here actually applies to new development teams. Within Contact, we grew the company from about five developers to about 45 with the supporting staff of QAs, project management, different people like that. We went up to about 80 people in total in a very short period of time. So as interest as we did this process, we were able to learn from it and apply what we've learned to AHAs to our new teams as well. Why did we do internships? Well, because we were growing so fast, we wanted a recruiting tool. We wanted to try before we buy and be able to take the rock stars from each internship group. And so, okay, let's bring this person on, let's bring that person on. Over the course of my time in Contact, we hired over 26 Newmont students from that process not only just in our development side, but also our professional services and our tech support depending on the different skill sets. In addition, it's a great thing to have sort of a methodology lab. So if you don't know if a new concept would work, this is a great place to try it because the cost is not as high. We paid, we contributed 8,000 a quarter to tuition and different fees for the students to be part of their new work program. Okay, so when we started this, we said, okay, we're going to set some ground rules for how to go about this. First off, we're going to use scrum. We were already using Adjom, the scrum process before. We said, okay, we're going to use the same process with them. We're going to take the time to do it right and invest. So the theory was if we invest in the interns, in the processes, in the standards that we put together and each iteration, we consistently invest in that that it's going to get easier and easier to train these new developers and we'll get more and more value from that. So we're going to say, you know what, we're not going to get caught up into it. We're going to take the time and invest in it. We're going to create an onboarding process that would include standards. A lot of companies have what they call maybe a developer handbook where they document, all right, this is how we go about business. So we are going to invest in that. We are also going to invest in company unique design patterns. I find it very interesting that a lot of people know about design patterns. They talk about it, but rarely do I see them actually use. The other aspect of design patterns is people realize that every company has their own design patterns. How does that company do their prep? How does that company interact with their database with the doubt? How do they do their window services? Is there a certain way that they've found that works really great? How do they do redundancy? You know, all companies have these design patterns and the tribal knowledge holders within the company have that knowledge. So our goal was we're going to document the ones that we're going to use so that each time we have a new group come on, this is how we do prep, this is how you do data access layer, this is how we go about doing unit tests, this is how we go about building our software so that they can get some of the ground rules up front and then hopefully then there's a better dialogue of value there. Where we're talking about, okay, now what about this? What about that? Continuous integration. Prior to this process we never had continuous integration in contact. And so this is an opportunity towards the methodology lab to say, hey, let's build continuous integration. We're going to take cruise control, we're going to set it up, get it so it's building. We're a document shop, so it's pretty simple to do that. And then we'll actually have it call our unit test, create up some sandboxes for our databases and have fun with that. And then the other item was we're only going to train for what is needed. So we knew based on the team that came in, all right, you're going to be doing web development. We'll only take the standards that apply to web development, the design patterns that apply to web development. Let's just teach them that and not anything else. The next team that comes in, okay, maybe you're going to do a Windows service. So let's take now the pieces that are related to that and teach them that. That shortened the onboarding program. We first did it because we would do their 10 week period of time each quarter and we did probably about 8 of them in total. When we first did it, it took me about 2 weeks to train and bring this team on board, which have already burned through a good portion of my time. But as we got better at this, I could train a whole team in about 3 days for whatever the project was, which was a huge benefit to be able to get going on the project. And then in each iteration as we do this, we're going to update the process. We're going to take the time and improve it and document that process. Okay, so through our iterations, what did we learn? What were the ah-has? As we're going through this again and again and again. One of the neatest ah-has was the idea of the milestone. Now this is not the milestone that you traditionally have where, alright, we get to this point and we've completed this project. We're down to phase 1 and phase 2. The milestone was really to say what I wanted to do was get the team to act as a team. And the problem was with a lot of the other development teams is that we were going so fast we're creating technical debt in our product that by the time we got ready to release it, it was a pain. It would take us, we had one release that we estimated cost us a half a million dollars just to release it. I mean that's huge, okay? Because it took about half of our development resources to go in to fix the technical debt, all the management pieces, the delay, all of it, it was horrible. And so the milestone was that we're going to take a point in time, whatever it is, that the entire team is going to say we are done. That it's coded, it's QA, it's documented, everybody signs off, we've met the acceptance criteria of those user stories, it is good. So what happens when you do that? So we're doing a four-week sprint and we've said the milestone is either a week or a two-week period and the whole team would get to that and some members were done with their work, other members were not. So we would have the other members help the other team members finish their work or maybe we have to do QA. So we had the whole team jump on QA. The point was we came to a point where everybody finished everything so everything was good. It gave opportunity for team members to work with each other, gave opportunity for the team members to work in the QA area, which was great because then they understood what it was like. So the next time they develop software they may make it a little bit better or they'll communicate better to the QA people. But at that point in time we would not move on until everything was good. And what we did by doing that is that our product always worked. The continuous integration was a huge help for that. The other thing we did was pass the knowledge on. A lot of times developers are known for just throwing the finished work over to QA. So here you go, test it, make it good. What we did is I required every developer to create a dev to QA document. And the rules was it has to have at least one sentence on there, it has to be a piece of paper and you have to give it to the QA guy. The QA guy has to say, got it, understand it. So I don't care how much you put on this document, the point is you have to have a sit-down interaction with QA. You have to write up something that the QA person is willing to accept, show them how to test it, show them what you were thinking, give them ideas of different ways to go about it, and then certify this document and hand it off. So I didn't care what was in the document, I just cared that the process happened. And that was great because it caused a lot of the developers to sort of say, oh wait a minute, this is a finish, this is what I actually need it to be, and so they go back and reworked it, so there wasn't a lot of going back and forth between dev and QA due to that. The other item we used was the wiki. Wiki is just a phenomenal thing, it's a quick way to throw up information if you guys have used wikis before. So we would capture any of the knowledge that we would gain, we started to build a knowledge base, terms, the design patterns, troubleshooting. A lot of times these new developers would come in, and the most common thing with the new developer is, how do I build your code? Maybe you have some third-party components that are a little bit tricky to install. Well, every time somebody had to go through some troubleshooting, we had to create a little page about what is it you ran into, how did you solve it. So each time they did it, when the new teams come in and they ran into, oh just go to that page right there, that's how you fix it. And we build this up over time, and the thing that was interesting is that all the other development teams in contact started using the knowledge base and the troubleshooting, and they started adding information to it, so that we didn't end up where individual teams were solving the same problem again and again, where this knowledge was now shared, first team that solved it, documents it, now everybody has the knowledge, so that the teams now work on the next problem to solve. Teach them how to fish, pair them up. There's an interesting thing I'm facing right now with Eugenius, and that is that in a Scrum team, not everybody can work on the number one task if they're the expert at. So if I'm a database guy, I may not be able to work on the database task every time. Behanding what's happening, I may have to go do some web development, I may have to go do some window service development. If the individual's qualified, let them do it. So with this it was, hey, we may have a guy that, we may have a guy that's an expert and a novice. Well, pair up the novice with an expert so that person can learn how to do that. And when you do that, the team first starts to work closely together, and second, you start to gain more and more knowledge, and so more of the team members become more capable and qualified to do the different tasks. And of course we have code reviews within that process. Retrospective, don't ever underestimate the value of continuous integration. I am a convert of continuous integration. It tells us how the code is built. The first thing I do whenever I have a new developer or a new team, go in and build the entire code base, everything that we deliver, and go install it on a virtual lab environment from beginning to end. So they understand what are all the moving pieces, how do we actually build it together, so if they were given an assignment after having gone through that exercise, they would know how to build the code. They'd also know how the continuous integration part should work so that they go and they change this line of code, the system builds it, tests it, and lets them know, gives them good feedback quickly. And it executes the unit test on that. Group design. Take the time, and it's such a temptation to go to ask. Take the time, have QA, have everybody who's going to touch this project be involved in the design up front. Have them understand the challenges that you go through and try to solve the problem. Why didn't you do it this way? Why didn't we go that way? If they're involved in that conversation, you won't have those questions, and it will reduce scope creep, it will reduce the lack of focus. You know, sometimes we just spin, but it's so costly as a development shock as people are trying to figure out how we're going to get to this end result, where if everybody's involved up front, they all gain that knowledge. And they know how to test it. And the QA guy who's involved in that, oh yeah, that's what they intended to do. It should be like this. Constant one-on-ones for feedback and early discovery of problems. When you have a new team or new developers, it is crucial to have almost every two weeks, if not weekly, one-on-ones for the first month or two. Understand where they're at. Understand what the challenges they're facing. Maybe they're put into a situation where they're not an expert. They don't know how to do that. The earlier you know that, the sooner you can put an expert with them and help get them through that. Or maybe you find out that their passion isn't here, but it is there. That open dialogue, move them to where their passion is. You're going to get so much more value out of doing that. A clear understanding of value. User stories and acceptance criteria. I am a huge fan of the card. Putting the user story on the front, putting acceptance criteria on the back, having that open dialogue, it's huge. And limiting the scope. If you say, okay, we're only going to do this, or we're going to do this good, and it's going to work, it's going to unit test, and we're going to have a finished product. When you do that, the team can produce that, and then all of a sudden they're done. And then they can move on to the next piece and the next piece. Too often teams come in and they try to impress, or they're new and they want to do a lot of work. They'll end up building something like this that takes twice or three times as long. And it's a waste of time. Whereas if they just do that, they can consistently deliver value to the customer. Remember to make your technical debt payment each straight. That is so key. Because without paying that technical debt, without helping them to understand what done is, too often they just build the product and we end up in a situation like I talked about before, where we have to pay the half a million to release the code. If the team accepts for what done is, and they accept for what that technical debt payment should be, maybe it's two or three unit tests per section or something. Whatever it is, define it upfront and consistently pay that. Over time, by iterating through this, your momentum will speed up. You know, speed up, you know, speed up. We just had a sprint review in contact, and one of my prior coworkers told me about their team and he said, you know, I'm so excited, I've got to tell you what happened. We went up there and in contact, they have probably about ten teams that are running. He said, our team was the only team that had 100% completion. Our team was the only team that had all the unit tests in place, and we completed what we committed to. Because they followed this process, and the momentum from the first time where we faster than any other team, other teams were faster than us, other teams had senior developers who could produce better code. But we learned from that experience, we iterated, we did retrospectives, we improved the process, we added more design patterns to it. So we actually had a library of design patterns. So when we wanted people to come in, we could have them create code very quickly. We already knew we had tested it, doing it that way, and so the speed at what these new teams could do was just phenomenal. Let me share one more story with you before I go to questions. Just go over my notes here, because I want to make sure I don't. Going back to AHA, when you can get a team to act as a team, to help each other when someone else isn't completed, but you're done, there's so much value in doing that. I had a, one of my prior bosses, was over in the gaming industry for the last 14 years. And he came into in contact, and he started introducing some different processes, some different business ideas and concepts. And I was always amazed that he had such a great insight to how should we do business. And so I watched and observed, and finally I realized what it was. In the gaming industry, you build what you call a studio, and the studio will last about maybe nine months. It's almost like an entirely new business from financials to development, HR to everything. And you'll go through, you'll build a product, you'll release the product, you have to make your money back in three weeks or you're a failure. That's how the gaming industry works. So he did that. Then he did it again. Then he did it again, and again, and again. And what it did is it created an opportunity for him to reinvent himself. A lot of times as we're doing development, we're just trying to make the deadlines immediate. And we don't have any of these time spans of breaks where we're able to sit back, and it's almost like if you were able to go to a new job between every string, you would redo the way you did things. You'd change a few things, you'd tweak it. But if we're just always at the same company that's moving forward, you don't reinvent yourself that often. And so he was able to do that and learn and sort of fine tune the process. The same thing with these interns is that every 10 weeks it was a whole new group. So we get to reinvent ourselves. We get to learn from what we did. And so the a-ha I'll share with you is as you're doing your work, if you can somehow create an artificial break and really have an opportunity to reinvent yourself. Now the retrospective is supposed to be a vehicle for that. However, I think we get into the habit of the retrospective. Yeah, sort of like this. You add it like that. Yeah, maybe we should do this. We're not really into it. So if we can make that retrospective work like that, then you're going to see a lot of value from that. We're willing to really look at it and say, what do we need to fix? And doing that off the retrospective probably isn't good, but every now and then maybe once a quarter would be very beneficial. So any questions? Actually just touching upon retrospectives. So when we have retrospectives, we'll list what we did well, what we didn't do well, and what we could improve on. And then we just kind of forget about it. Have you guys had to tackle that sort of issue where then all of a sudden an expert comes up and you take a look at the stuff that you said last week. Like, oh yeah, I forgot that I said that we needed to improve that. I'm just wondering how you guys actually deal with this retrospective and actually put things in. There's two things that we've done. One is in the wiki, we capture the retrospective. So in your scrums, maybe once a week you can go over that retrospective and say, hey guys, this is what we talked about. Are we still in track for what we said we were going to do? The second thing, and not necessarily tied to the retrospective, but that helps to sort of re-infuse focus is we do what we call product backlog grooming. Where we get together for one hour every week with everybody and we go over our product backlog. And in that we'll take whatever, either dive deep on a particular subject or whatever we need to talk about to ensure that we have the right focus. And so that activity also lends itself to some of those discussions. Oh yeah, remember we said we weren't going to do this. Let's do that because we're going to have this work that's coming up. Any other questions? Mostly from an administrative standpoint, how did you deal with non-performing interns? Brutal honesty. Okay, and then you had any leverage over the grade? Did you assign grades? Did you find some kind of feedback to them? I would failed them. So if I said you'd get an F, if they weren't active, because one of the things that a lot of the other companies that do this and say this kindly, sort of they bring it in, here's a project, go do something. And more likely they're going to throw away whatever work they did. That's not how we approached it. You're here, it's going to be extremely hard, you're going to require to work hard, you're going to put whatever you built into production. So if you're not cutting it, I will pick you out very quickly. However, we will have many dialogues prior to me saying you're out. And I'll be very honest with you. I got known by a lot of the developers in the company and of the student body that I was very grueling honest. But I was like, you know what? You're not cutting it, you're not doing this, and this is why. So what you need to do, what I would suggest is these different things. And you pick what you want to do, but you need to fix this problem. And I'll help you, however I can. We've got other people who can sit down to help you with this, we can pair you up with an expert. We're going to give you the opportunities to succeed, but it's up to you to succeed. And if you don't succeed, you're out. So what was your intuition, right? I had, I only had one student I almost kicked out. And phenomenal turnaround. As a matter of fact, I had many phenomenal turnarounds in the students, because I was almost straight. I had him crying in front of me, and then they changed their habits. And I had one student where the faculty says, what did you say to him or to me? Because he is applying himself in all his classes now, he's stepping up. One of the things that's a good motivator is at Newmont, they go about 90,000 in debt for their education. And they start to realize they're out and I'm about to graduate and I'll tell them I would not hire you nor would I ever recommend you because you can't do this. But I can tell you what you could do to be hired if you really want to work at it. Any other questions? Okay, thank you everybody.