A new team's first Daily Scrum

We spent the first several weeks in my game programming class covering the basics and exploring two platforms for game development, Slick and Unity. On Monday, the eleven students decided that for their semester project, they would like to work on one big team to try porting Morgan's Raid to Unity. I decided to mentor the team using Scrum, since that has worked so well for me in the past. For Wednesday, I put together a product backlog and the team had its first spring planning meeting. While I had recommended that the students read The Scrum Primer, I got the distinct impression that the vast majority had not done so; in their defense, I had emailed the link Tuesday night.

The planning meeting went well, although fifty minutes was awfully tight to introduce the fundamentals of Scrum and to do the planning. I used my Scrum diagram as a reference to talk through the process. We were missing three of the eleven team members, but we were still able to get a reasonable number of stories committed for the first Sprint.

Today was the team's first "daily scrum." At 8am sharp, everyone was present. I told them to get into a circle and report what they had done since last time, what they had planned for next time, and what were the impediments. They got up and moved to the open area in the front of the classroom, while I stood behind the teaching station.

Here's where the team really surprised me. In using Scrum with students many times in the past, I have found that they find it challenging to report to each other, that they prefer to report to me. I wrote about how my Summer team was able to leverage the physical space to have productive Daily Scrums, but that team was half comprised of people experienced with Scrum, so their team-facing attitude was to be expected. This team of eleven had one student with Scrum experience (Tom), and the rest had none. They formed the circle and showed a few signs of anxiety, but Tom started right in with his daily status. He passed it on to the teammate by his side, and the whole stand-up meeting went as smoothly as one could hope.

There are four differences between this team and those from my past experiences, and I suspect that each is a contributor to this team's success. First and foremost, I learned a lot about managing a Scrum team through my experiences last academic year, and so I was more careful to separate myself from the stand-up meeting. Second, there was the issue of physical obstacles between me and the team: as with the Summer team, the furniture provided a convenient separation. Third, there was exactly one team member who had Scrum experience, and he showed no hesitation in starting the meeting and reporting progress to the team. Whether he meant to or not, his example provided the perfect template from which the other students intuited the expected social behavior. Fourth, all save one of these students have taken previous courses with me in which we repeatedly applied principles of agile development. We did not use Scrum in  particular, but we discussed the philosophy and the implications as well as learning the practice through a six-week project in two deliverables.

I wish I had more data to support that last point. I would love to be able to claim that the students' experience in CS222 is a contributing factor to their ability to work in teams in upper-level courses, since that's one of the explicit goals of CS222. Unfortunately, the assessment data is not that rich. I mentioned three other contributing factors, and there are undoubtedly more. Still, it's anecdotal evidence that some combination of my teaching and the curriculum are working in tandem to improve student learning experiences.