Blog

Using Scrum on grad school projects

Last week I finished Module 1 of the UVa McIntire School of Commerce grad school program Im in, for an MS in Management of Information Technology.  It was a great 2 weeks, and a lot of fun and hard work.

MSMIT banner

The MSMIT program at McIntire is a 12 month program for working professionals, where we typically meet for 3 long days a month, with group work, projects, and lots of reading and research in between the monthly sessions.  Module One (or Mod1 as we call it) is different however.  This is our full time 2 week residency at UVa, where we study various foundational IT topics in class for 8 or 9 hours.  Topics like:  Database design, Data network design, UML modeling, the Zachman framework, Business strategy, Web 2.0, Datawarehousing, IT security, and more.

Team 11 hard at work

But thats just during the day.  At night we work on a group project, in addition to some homework assignments, guest lecturers (we had some great speakers visit), and social events to network with our classmates.

The group project for Mod1 was to come up with a Web 2.0 initiative for a health insurance company, design the product, research and estimate its business value, and prepare a presentation for the class.  At the end of the two weeks, we had two things to deliver.  First, we had to turn in a complete Zachman framework design of the product.  Second, we gave a presentation to our classmates as if they were the Board of Directors of the health insurance company and try to convince them to fund our project.

Team 11 - Adil standing next to the backlog (behind him)

I had the pleasure of being on a great team.  At the beginning of Mod1, each group had to complete some team building exercises, where we decided what the ground rules for our group would be, what our group and individual goals were, and how we wanted to operate as a group.  I found this to be a more valuable experience then I expected, and I plan to use it more often in projects at work.

One important decision that our group made right from the start was to use a lightweight version of Scrum to organize our team.  Our teams goals were to be very efficient, and to focus on the quality of our work, not the quantity of time we spent on it.  Since two of our team members had previously used Scrum, and a third is a rugby player (Tim), using Scrum was a natural fit.

We ran 1 day sprints over the two weeks.  We didnt keep a burndown chart, since that would be too much overhead.  Our planning sessions basically were to update a list on the wall with everything we were going to do that night, and then go around the team and let everyone pick their own tasks until all tasks had been assigned.  We didnt bother with estimates on those tasks since the granularity of the sprint was already down to just one day.

Tim running a stand up

At our next meeting, we would do a quick stand up to update the team on where we stood on our assigned tasks, and then we usually did a demo of our tasks.  This “lightweight Scrum” helped keep us very focused on our work and the tasks assigned to each of us.  At OpenSource Connections, we did a similar thing for the Rails Rumble last year, which is a 48 hour coding competition.  During the Rails Rumble, we would plan sprints of 2 or 3 hours each, at the end of which we would demo our progress to each other.  It was lightweight enough to work in a very tight timeframe while still keeping just enough process that we all stayed focused on the job at hand.

The other efficiency thing we did was to “time box” every discussion we had.  Many parts of the group work involved design discussions about what we wanted to do for our projects, debating the pros and cons of it, reviewing each others work, etc.  To keep these discussions from going on all night, or wasting our time debating things in detail that might not even end up in the project, we would put a time limit on everything. 

Every day we tried to rotate a facilitator role, and that persons job was to keep the discussions going smoothly, and they were usually the person who would pipe up with “how long do we want to spend on this topic?”  We might set a time limit like 15 or 30 minutes, and then Adil would set the timer on his iPhone.  When the timer went off, we would cease debate on the topic and try to make a decision.  If necessary, we would extend the time, but the goal was always to stay within in a timebox so we wouldnt be up all night and could get some rest (or at least head over to the bar!).

We had a lot of different personalities on our team, and lots of different perspectives.  But we got along great as a team and I think the agreement on ground rules and the use of Scrum helped out a lot with that.

I think the way we came up with ideas worked pretty well too. We started by encouraging everyone to write any idea they had on yellow post-it notes, and stick it up in one corner of the wall (you can see Adil pointing at the post-it notes in the photo below). It didnt matter if it was a good or bad idea, the point was to generate as many as possible and get them on the wall. Similar to the way people propose sessions at an open spaces conference, each person would read their idea as they posted it to the wall. No criticism or debate was allowed at that point.

Team 11 Brainstorming

The next day we grouped the post-it notes together by ideas that were similar or could be easily combined together into the same project. It was clear that we had a lot of ideas around mash-ups, since that was the largest number of post-it notes. But we didnt choose the idea based on quantity.

Arash had drawn a map on one whiteboard of the goals, strategies, and problems at the health insurance company (see pic below), and we began to move the post it notes onto the whiteboard, lining them up with what goals/problems they addressed.

Adil pointing at the project goals map

At that point we finally started voting on what idea to go with. Everybody picked their 3 favorite ideas, and the three with the most votes were the finalists. We debated those three ideas in more depth, bounced ideas off Prof. Grazioli, and then picked our project idea.

Although it sounds a little complex, I liked this process because it encouraged us to all be creative, to consider all ideas, to map those ideas to the goals of the project, and ultimately to create a consensus around the final idea. I have a tendency to push for my favorite ideas, and this process helped make sure I didnt force my ideas on the team, and ensured that we carefully and creatively considered all the ideas.

In the end, our team ended up proposing an incentives program based in part on an iPhone app that would record your exercise and upload that data to the health insurance company, which would then convert that data into “health points” for use in contests with fellow employees to encourage healthy lifestyle changes.

Team 11 Project Overview Slide

All the presentations were given on Friday, and the professors split the class into three different classrooms of 4 or 5 teams each (there were 13 teams total).  Each team presented to their classroom, and then the room would pick which team should “advance” and be one of only three teams to present to the whole class in the afternoon.

Our team was really honored to be picked as one of the final three teams to present to the whole class.  It was a lot of fun.  I have to also tip my hat to the other two final teams since their presentations were not only excellent, but I was also very impressed with the depth of financial analysis they incorporated. (Im looking forward to future modules where Ill learn the finance skills to be able to do the same since finance is not my background).

We kicked off our presentation with a video to illustrate the idea of our product.  We had a lot of fun producing it, and I think our classmates enjoyed it too.  Youll have to pardon the poor resolution – it was my first time using iMovie and a flip camera, and I didnt get the conversion right.

Just for fun, I also took a few clips from our filming and made an “out takes” video.  We got to show the outtakes to the whole class too after our presentation, which I hope added a little playful humor to the end of Mod1. (Prof. Grazioli showed some very funny retrospective slide shows that were the real hit of the afternoon however!)

Mod1 was a great experience.  I advanced my IT skills, teamwork and leadership skills, but perhaps most of all made some great friends through the shared experience of great professors, very interesting classmates, and of course sleep deprivation.  Im looking forward to Mod 2!

Team 11 was:  Tim Bucher (Booz Allen Hamilton), Adil Qazi (Freddie Mac), Arash Sadati (International Monetary Fund), Arin Sime (OpenSource Connections) and Mark Widener (Virginia Air National Guard).