 Hello. Thank you and we are so excited to talk about our project. We worked this summer with summer, we ran a summer internship program and we have some excellent results to share with you. We've been running agile models for a couple of years now prior to having the summer interns join us. And so this is our story. 0 to 60 is a reference to obviously going faster and increasing your velocity if you're an agile person. You know that means that like your capacity to produce these results. My name is Amber Stokes. My colleague Rex Lorenzo is going to cover this second half and Deborah Kearney was a collaborator. She presented this same talk with us as joining for Zoom from Australia. So the main theme is what do we mean by a traditional model? So we're saying we did a non-traditional agile team. What do we mean by that? In this case we're referring to the myth that there's just one way to adopt agile. You might be kind of hesitant because you're like oh I don't really have the staffing, the resources. I don't have the roles. And there's good reason for those concerns but we want you to see that mainly agile and traditional sense is a traditional team would be a fixed team. It's an established team. You don't have transitional workers is what I'm saying. So you don't have like your staff you always work with. So these people are coming in summer, they're new, they're four people, they're students. We've got to get raw talent, hire them, get them up to speed, keep them simple and then build the complexity and make success. So the main points of the talk, I have a couple of slides and I'm going to hand over the rest of the talk to the RECs. The roles are critical. If I'm going to talk about the roles, if you know the roles, you know the roles are critical and agile. A lot of people try to wear the three hats that are required and it's tough. You're going to run into some problems maybe trying to do agile that way but it's possible you're doing like some form of agile. The details on how UCLA leverages our student internship is to maximize velocity as something RECs will go over and the success is shared, final outcomes per student. So we have like each student had some like artifacts, things that they accomplished individually and as peer programming and lessons learned. Oh no, I'm just on my first, sorry. That was a long first slide, sorry. Okay, so what is agile slum? How many people know what agile is? Can I just get a sense of the room? Okay, so that's a growing number of people I think from the last conference we presented last year. Have you ever wanted to use agile but there's like parts of it that aren't working because of your staffing situation? I just see one person. Okay, you're going to understand. So there's things that you can take away from our talk even if that does not apply. Okay, so there's going to be agile, how you're a story and then maybe we can also share stories later after we're done presenting. So our strategy was to rework the traditional roles. The traditional roles of agile are product owner, scrum master and developer. Product owners are always looking at the business needs of the feature, development, prioritization and the scope. A lot more to it, believe me, but if you know the product owner role there's a ton of discussing, talking with stakeholders. You have to be very good and opinionated and know the history of a place I think to do it well and our product owner, Deborah, does a very good job of that. Scrum master, that's my role and sort of like the social aspect of me is what makes it work. I pretty much can work with any person in trying to motivate. What I do is I understand the people in the process. I'm constantly aware of that. I'm fine tuning. I'm removing roadblocks for people if there's people not available to answer questions for students particularly. Developers are the ones that estimate the point values. They know what the work requires. They're the check-in point for technical possibilities, difficulties. We can do that. We can't do that. We do fixed length iteration. All summer long we did one weeks. If you do sprints, that's fast. Our first meeting would be on a Monday. It would be to our meeting and then we'd have 15 minutes stand-up a week all summer long, really fast. And then now it's academic year. We're back into our two-week cycle. I would say the structure is really important in Agile. If you're keeping structure, you have all these different meetings. You have a planning meeting. It's usually an hour for the two-week sprints. We have stand-up meetings 15 minutes. We have demos and retrospectives. Motivators are story points and velocity. This was just an overview. I know a lot of you know, but about half the room didn't know what Agile maybe was, so I wanted to cover that. Let me tell you more specifically what we did this summer. Our goal was to adapt this methodology. We were going to take these transform, these four students, which is basically double our staff almost. And we're going to take four students. We're going to make them productive members of our development team. And we have two and a half months and we're going to do amazing work. We're just like from day one, we're just really motivated for that. I'm the Scrum Master. I do team building. One of the things I did that not as traditional and really worked hard at taking them out to John Wooden Center to shoot baskets, shoot basketball, and do some things that are more fun and social so that we can get to know the students right away so that we can kind of build the community, build the team. Calendaring. I like calendaring. I don't know why people don't like doing that. I just love keeping people in space and time in the place they need to be. It's my personality and I love making sure that the short sprints can be adjusted as needed where vacations come up or students come up. We clear road box. A lot of that is just because if there's people not available to clear the road box of the students, I actually sit in the common area and I really like that that I don't have an office. I like to sit in the common area where people talk to me and stop and ask questions. That's part of the Scrum Master role is just constantly monitoring and taking feedback and changing things when the team isn't happy with the way our meeting goes or some things we're working on. Lead developer. This kind of looks like Rex. I think this is Rex. He's a very really good hands-on mentoring. He's there from the very beginning from planning the internship. He's there to hiring hands-on mentoring, sitting down. He'll tell you more about his details actually with how he does peer programming and all that. Task identification is like matching tasks to person. For students, he has to think about all these things. Backlog refinement is a shared task, but you have to break everything up into blocks and be familiar with middle code. This is my last slide and then I'll be handing it over to Rex. The backlog owner is a very time-intensive role in our organization. They assess and prioritize the business needs. Their stakeholders are very vocal and they're very like interactive with this product owner and they have a very good dynamic. I like to see them constantly talking about things and I think they and it's not like always calm like sometimes we get into these really intense conversations about don't you remember this or that and I love that about that our meetings can go in those directions with like a lot of emotional charged information and things like that. I think it adds a lot of vitality to your meetings. It's definitely interesting and helpful to hear what people think. They are there to communicate the vision to the team and the stakeholders. So if we change directions as needed, you know, those people are the leaders. So up to this point I've shared some overviews of our adaptation. From here Rex will go into the details. Those will cover our shared successes, our final outcomes for student and the lessons learned and we hope that every summer we will improve. This is just the beginning and I think we want to have competitive internships so that's why we do the best we can. Thank you Amber. So how do our summer internship fare? Well during the summer we're 300 times more productive than any other time of the academic year and you can say it's probably because we added four developers but remember these are student developers who've never used Moodle before in developer sense and many of them haven't even written line of PHP code before. So how do we onboard these four students quickly enough to become productive members of our team? Cover section of our task and building it up throughout the summer. And these students they all brought in their own experiences in front and back end work and soon our students will provide feedback not only on their own projects but to each other's projects and all this increased collaboration and communication really revitalized the workplace. Each day brought in new challenges, enthusiasm, creativity and energy. These are our students. This is what the picture taken from our end of the summer lunch to celebrate their successes. This is about the projects that they worked on, their story points and during the summer we accomplished several projects. We had a project where we automatically converted video files that were uploaded to our Moodle system to a streaming server called Kaltura. We worked on a new date picker. We worked on adapting the Moodle room snap theme to our custom course format and we also changed our development environment from vagrant to docker containers. And also this was the first job for many of them as well. So how do we get there? How do we onboard our students? So our onboarding process is first you start everybody off with medial tasks. This is code cleanup. I call these medial tasks because they aren't fixing any real problem that anybody really sees. They're not really fixing any bugs. They're not really, it seems kind of pointless maybe, but it is really valuable for a new developer to get used to looking at the code and also running some plugins. So Moodle provides a couple of cool code checkers that are very useful. They tell you if your comments are missing a period at the end, if your variables have underscores in them, things like that. And even though you're changing code that shouldn't have any side effects to it, you still need to test it. So it gets our students used to going to Moodle and navigating to exactly where these codes, lines of codes are being run. Then we move on our students to bug fixes. These could be simple UI issues like just a font needs to be bigger here, but it needs to be moved over or functional bugs. And throughout this process, we're trying to gain a sense of achievement, of accomplishments for our students. And then when we feel like they've leveled up, they feel like confidence in system, they move them on to our bigger individual projects, our summer projects that take a month or so longer to work on. And during this time, we also do develop a sprint dedicated to having our students contribute code back to Moodle. So it gets them another sense of achievement accomplishment, where they get to contribute the patches that they made earlier in the summer or maybe a patch that we worked on during the academic year. They clean up the code and fork the Moodle repo and go to the tracker and just submit their change request there. And then towards the end of the summer, we worked on automated testing. We did a workshop on Behat and we had everybody write a unit test, Behat test for the features that they worked on or the bug fixes that they worked on for the summer. So what are some lessons that we learned? So we originally planned to add automated testing at the end because we didn't want to overburden our students with too many things to learn. But what we found out in our exit interviews was that our students loved automated testing. And our students didn't view learning a new thing, especially if we add to the development toolkit as a burden, it was actually very, very cool for them. So next summer, we're going to plan on having automated testing towards the beginning of summer so they could actually use those skills for their bug fixes for the individual projects. And also throughout the summer, we kept to a one week sprint. So in the beginning of summer, that was really great because it gave students constant feedback and we were able to give them more projects in a weekly basis. But as they moved on to their individual projects, the bigger projects that took longer, longer to work on, these weekly sprints it seemed more onerous to them because they kept on having to talk about the same projects week after week saying, I'm still working on that. And so next summer, we're planning on switching to a two-week sprint model to give students more time to focus on the bigger projects so they don't lose that sense of achievement, that sense of momentum they got in the beginning of the summer. And also we discovered that the students that participated in pair programming met their deadlines and project goals more consistently. So the whole adage, having two heads are really better than one. So here, yeah, so maybe next summer, we're planning on having pair programming, not just encouraging it, but we're going to try to make it mandatory. And we're trying to introduce it earlier in the summer as well, where they get to work together, working on bug fixes rather than just working together on their summer projects. So that's our presentation. We talked about agile, the different roles that we had, how we adapted them, our onboarding process, and also some lessons learned that if you were to have your own summer internship program, or if you were to onboard a new developer, these are some cool things that we discovered. And we have some time for Q&A, Amber and I, if everybody has any questions. And this is a picture from one of the basketball outings that Amber organized. Yes? So what we found is, yes, the question is, do we fund any personality conflicts during pair programming and stuff like that? I think all our students got along pretty well. The ones that didn't really participate in pair programming, their schedules were really lined up, I think. The two that did get really well together, they're early in the morning together and they're like joking around together a lot. So like, yeah, there are personality conflicts, if they do match up well, then pair programming is more efficient. Yeah, so that's why the, so a lot of those things can be solved, like how do they work well together? So you can make that environment like beneficial right away. And the ways you can do that is like, first of all, you get along with your colleagues as an example, because those are students and that's the first workplace, right? So you got to kind of like model it, and then you have to give them good, you know, space to work in. So we just happened to have, it just kind of worked out, Amit and Emily got along really well. Like they were just laughing all the time and they got along. They, you know, maybe just asked each other's questions, but their desks were like back to back. And I think that's actually really important, the physical arrangement of the space. And then the other space was William and Hannah, and they were like separated a little more and like kind of straight away. And they didn't collaborate as much, but there's other factors involved. But I think that the physical space, the time they come to work, any temporary, any transitional stuff, that will affect your, I think, success. Okay, so the question was, how do we get story points? How do we evaluate story points? So we did something called an estimation poker. So everybody had had a set of cards where they said like one, two, three, four, like we're rating up story points from one being easy to eight being really hard. Then everybody, we discussed a problem, then everybody will choose a number that they think the task is, and then we'll do one, two, three, everybody would show their cards. And if there's any big discrepancy between point value, then we discuss the issue more until we get a consensus of a single point value. So yeah. And I think the important part of that was that over time they built confidence in their ability to estimate their numbers. So with everything with these students in this group of people is like practice small tasks for success so that they succeed over and over. Yes. Yeah. So the question is, when we recruit the students, do we have any other criteria? Yeah. So I'm a big fan of people who participate in hackathons, people who are really able to quickly learn new technologies, able to take on tasks and produce something quickly. So hackathon experience, I look for that really highly in resumes. Yeah. And hackathon is where you have the only 24 hours to create a project. So it's very, very useful skill. Nick. Yeah. Yeah. And also PHP is not a requirement to be, to have a job. It's a nice side benefit, but we view just PHP is something, it's not an essential skill because you could easily learn it. Once you know C, I think it's pretty simple too, but... Oh, yes. So what's our student retention like? Yeah. Where we're thinking, every year, it's very rarely that we get the same students again. I think it only happened once. So every year it's a whole new batch of students. Yeah. You have to remember that we're not Los Angeles, so it's very competitive. There's a lot of student internships, but one of the comments that really stuck out to me at the end when we were like, talk to the students about what was this experience like with you. They said, we love that we're going to be on CCLE doing our classes and we made that in a lot of the projects in big companies, they don't get this. That's just like a silo they did and it never really goes live. What they do is live. It's real. It's something bigger and it's also, you know, gives them a job, a real job experience. I think that's very valuable. Okay. Thank you.