A recent tweet by Steve Keinath aka @keinath about using Agile in the CS classroom led to a discussion between myself and John Miller aka @agileschools. Twitter, while great for starting discussions and connecting people, is not-so-great for conveying nuanced thoughts.

So here I’ll try to summarize my thoughts on Agile in the Computer Science classroom, based on my experiences.

Background

In Winter Quarter 2009 at UCSB, I took an excellent graduate class called Scalable Internet Services (290F) taught by the amazing Klaus Schauser (founder of Expertcity aka GoToMeeting and more recently AppFolio) and Ross Hale of Pivotal Labs.

The basic idea of the class was to teach us how modern websites (as of 2009, of course) are built. We learned (from the top of my head) Ruby on Rails, Amazon EC2, vertical scaling, load balancers, git, and Agile software development practices. All this theory was backed up by a course-long project, created by a group of 5 to 7 people.

It was during this project that we were exposed to Agile software development in a practical sense. Ross helped us understand and apply Agile development practices to our projects. We came up with user stories, broke those down into features, estimated the hours each of the features would take, and ordered the features into a queue. Then, I believe we had one or two week sprints (I can’t remember the exact length of a sprint) where we would work on the features. We used the scrum methodology, along with pair programming and TDD. Klaus and Ross took the place of stakeholders in the scrum system.

The class was excellent and was a great introduction to a wide-range of technologies from people who are actually using those technologies in industry.

Also, I should note, as it’s relevant to my thoughts on this class, that I later had professional experience with scrum. When working at Microsoft as a full-time software developer, my team switched to a scrum process, instead of the waterfall method we had used previously.

The Good

Now that I’ve explained the class and my experience with scrum professionally, I’ll share what I thought was awesome about using scrum in a CS classroom for graduate students.

Exposure to Agile

Using scrum in class was a great way to understand what scrum was really about, rather than simply reading a book. This exposure made it much easier to use scrum professionally. I think I was also able to convincingly advocate for the change to scrum because I already had some experience. I could draw parallels for my coworkers between what we were already doing and what we would do in scrum (and how we could benefit from the sprint model and frequent feedback from stakeholders).

An additional benefit was simply the exposure to a different style of software development. It’s quite powerful just to start thinking that there’s not one way to develop software, especially in school.

Benefits of Pair Programming

Pair programming was hard to schedule as grad students. In a team of five, finding someone to pair with was difficult, and honestly we didn’t do it as much as we should have.

That being said, those times that we were able to pair program were eye-opening. It was startling to see how clear and high-level you can think when you’re not driving the keyboard. The other huge benefit was the transfer of knowledge: How did you make emacs do that? What Ruby feature is that? What command-line program did you just use?

The Not-So-Good

Ultimately, using something like scrum in a quarter-long (10 weeks) collaborative project for graduate students was not effective. The simple problem is: the amount of time that students can devote to a class fluctuates wildly week-to-week, mostly due to outside demands (other classes, Teaching Assistant responsibilities, or research). Some weeks in our stake-holder meetings, we made no progress, not burning down any hours or completing any features. This made us feel like crap, and made us look bad that week to our stake-holders.

Also, we didn’t have a chance to have daily standups, because we weren’t in the same place every day at the same time.

However, by the end of the class we had a complete, full-featured, Ruby on Rails website running on EC2. (Ours was a cool private torrent site where you only seeded to or leeched from your Facebook friends.) How did that happen? Well, some weeks were more productive than others. Much more productive.

So really, the problem was in the variability of hours students could devote to the course. I think that this variability obscured some of the benefits of Agile.

Advice for Agile in the Classroom

I think that using agile software development techniques in the classroom is an excellent idea. Exposing students to new ideas and approaches to developing software should broaden their thinking and should prepare them for real-world software development. However, any class that takes this approach, that doesn’t have an exclusive lock on the student’s time (like a dev bootcamp might), needs to factor in the variability of the student’s time.

So blindly applying the scrum model to the classroom will not be as effective as some kind of variation that keeps in mind the student’s time. I’m not sure exactly what that is yet. Do you have any ideas?

Bryce Boe reminded me that the class was taught two more times by a different Professor, Jon Walker CTO of AppFolio, so maybe Jon’s updated the course.