I just read through the student evaluations from Fall's CS345/545 HCI class, a topic of many blog posts in Spring. They are quite positive, with the vast majority claiming to have enjoyed and learned significantly from a team-oriented, "real-world" project experience.
The request that shows up the most is for more explicit milestones during the semester. I had mostly left milestones up to the individual teams since each project had different characteristics, but in retrospect, I could have offered more assistance here. Perhaps next time I will use timeboxing techniques, forcing the students to complete vertical slices and deliver working code on a regular basis; without this, several groups meandered through feature development.
A few students requested more time invested at the beginning of the semester explicitly teaching Android development techniques. That is a reasonable request, although I would like to be able to sit with these students to discuss what they really want. For instance, one student requested more examples, but there are myriad examples online and packaged with the Android SDK. Another student complained about the online resources feeling "sort of scattered". These students clearly missed the point that such is the nature of modern software development: examples and resources are scattered throughout the Web and the library, and gaining experience in dealing with this was an explicit goal of the course. In the student's defense, I did not directly assess their capacity and learning with respect to navigating this information. Still, I think that this shows that students often come away from coursework with the wrong impression, that there is a Single Truth and the professor has it, and that every problem has a solution in the textbook somewhere.
Most of the departmental evaluation form deals with 5-point Likert scales, though under "Overall rating of the instructor", I received my first 10 out of 5. The student actually wrote in 6, 7, 8, 9, and 10 so that he or she could circle the ten. It made me grin, though I still recorded it as a five in my database.
I will share with you, loyal reader, the best of the bunch:
What aspects of the course did you especially like?
The freeness
How can the content and the instruction in this course be improved?
More formal structure.
Such are the paradoxes of higher education!
Wednesday, July 28, 2010
Saturday, July 3, 2010
More thoughts on Fall's Game Programming class: The four options for ScrumMasters
I am glad I picked up Agile Game Development with Scrum since it has given me some concrete ideas to consider for Fall's game programming class. Because of the number of participants, we will need to have multiple Scrum teams. If we follow Ken Schwaber's suggestion for optimal Scrum team size of 7-9, I will have three to four teams, although the precise team sizes will depend on the results of the release planning meeting (yet to be scheduled).
The issue that I will explore in this post are three possibilities I have for who will fill the role of ScrumMaster for these teams. Briefly, Scrum thrives on self-organizing teams. I am taking a significant risk by trusting my students to effectively self-organize and deliver the promised software system. While I cannot control the chemistry of teams, I have seen Ball State undergraduates at their best, and I have faith in these students. The ScrumMaster is neither a developer nor a manager but a facilitator. The ScrumMaster's primary role is to remove the impediments that prevent the team's success. For a nice introduction to Scrum, I recommend The Scrum Primer.
The first and most obvious solution is that I could act as ScrumMaster for every team. This would have me in two Scrum roles: Product Owner and ScrumMaster. This would work as long as there are no more than three teams at any time, since this would allow for three 15-minute daily stand-up meetings during our 50-minute scheduled timeslot. Of course, that means that three stand-ups is all we could do in a 50-minute slot, and the teams would have to be large. The advantage is that I would be in direct communication with every team, and I could use my experience and expertise directly to help remove obstacles. Also, I could lean on the project co-PI, Ron Morris, to be the Product Owner while I focus on being Scrum Master for multiple teams. This would require that Ron be free during out class time, and I don't yet know his Fall schedule. There's also a very talented History graduate student, Michael Smith, who might be able to act as Product Owner in Ron's stead if he was not available during our scheduled time slot.
While this may appear ideal, there is a significant complication in the Sprint Retrospectives. These meetings are an extremely important part of the process because they force reflection, and reflective practice is perhaps the most important skill to teach in undergraduate education. However, these Retrospectives are timeboxed meetings moderated by the ScrumMaster, and there are simply not enough scheduled contact hours for me to hold honest Retrospectives with every team. More specifically, in a 50-minute meeting at the end of a Sprint, we won't have time for a multi-team Sprint Review and individual team Retrospectives if I am required at each Retrospective.
The next option is that one undergraduate on each team could take this role. The main problem here is that I don't image this role shall take the 10 hours per week commitment that I am asking of all the participants, and so the student in the ScrumMaster role would also be a part-time regular team member. The biggest risk, pointed out by Clinton Keith in Agile Game Development with Scrum, is that "the team assumes the role is a leadership one, [and] they defer ownership to the ScrumMaster" (p.51). This would be disastrous: I have been in learning experiences where students lost the sense of ownership over the project, and this destroys morale and productivity. The advantage to this approach, however, is that each team could have a 15-minute stand-up at the start of our 50-minute slot, and that leaves 35 minutes for other activities, such as Scrum of Scrums or Communities of Practice meetings. As Product Owner, I could float between teams during the stand-ups, and we would not be limited to three teams. This also frees up the schedule at the intersprints so that the Sprint Review, team Sprint Retrospectives, and Sprint planning can all move forward within the alloted time.
One may immediately and justifiably raise the question: how will I know if an undergraduate is qualified to be an effective ScrumMaster when so many of the requisite skills are unmeasurable? My answer is somewhat pithy: I'm not sure if I am a good ScrumMaster, so we may be no worse off! This also raises another important question: would any undergraduates signing up for a "Game Programming" class actually want to do this? Clearly, I would need to know the answer to this question well before we started any sprints! For those of you who may be wondering about the curricular implications, don't worry: I designed the syllabus in such a way as to promote this kind of project-based learning, in which students specialize in certain areas and experience the rest through legitimate peripheral participation.
A third option involving only undergraduates is that I could have one or two students who act as ScrumMasters for multiple teams. Keith suggests that a ScrumMaster can handle two to four teams. If I had one ScrumMaster per two teams, then 30 minutes could be devoted to stand-ups during our 50-minute slot, and that leaves 20 minutes for other activities. I could still float among teams as Product Owner, and the student ScrumMasters would not need to be developers on a team. Ideally, then, these undergraduate ScrumMasters would be putting in the same time as their developer counterparts.
There is a fourth option that brings in a few extra people. It so happens that I have two graduate students who have asked if they could work with me in the Fall. I suspect that both had research-oriented programming projects in mind, but potentially, I could tap one or two of these to be ScrumMasters for graduate credit, and I could have them document their experience in a technical report. If I had both and no more than four teams of undergraduates, that brings us to two 15-minute sprints and 20 minutes of miscellany during a 50-minute scheduled time slot. Also, being graduate students, and all else being equal, they may have an easier time learning ScrumMaster techniques by reading about them. However, I do not know if any grad students are actually interested in this, and I assume it goes without saying that I cannot afford to send anyone for real ScrumMaster certification.
It has been useful to me to write out the details of these four options, and I hope you, kind Reader, have enjoyed the exposition. I hoped that one of the solutions might outshine the rest as I wrote this, but I am still uncertain. I welcome your comments as I consider my options.
The issue that I will explore in this post are three possibilities I have for who will fill the role of ScrumMaster for these teams. Briefly, Scrum thrives on self-organizing teams. I am taking a significant risk by trusting my students to effectively self-organize and deliver the promised software system. While I cannot control the chemistry of teams, I have seen Ball State undergraduates at their best, and I have faith in these students. The ScrumMaster is neither a developer nor a manager but a facilitator. The ScrumMaster's primary role is to remove the impediments that prevent the team's success. For a nice introduction to Scrum, I recommend The Scrum Primer.
The first and most obvious solution is that I could act as ScrumMaster for every team. This would have me in two Scrum roles: Product Owner and ScrumMaster. This would work as long as there are no more than three teams at any time, since this would allow for three 15-minute daily stand-up meetings during our 50-minute scheduled timeslot. Of course, that means that three stand-ups is all we could do in a 50-minute slot, and the teams would have to be large. The advantage is that I would be in direct communication with every team, and I could use my experience and expertise directly to help remove obstacles. Also, I could lean on the project co-PI, Ron Morris, to be the Product Owner while I focus on being Scrum Master for multiple teams. This would require that Ron be free during out class time, and I don't yet know his Fall schedule. There's also a very talented History graduate student, Michael Smith, who might be able to act as Product Owner in Ron's stead if he was not available during our scheduled time slot.
While this may appear ideal, there is a significant complication in the Sprint Retrospectives. These meetings are an extremely important part of the process because they force reflection, and reflective practice is perhaps the most important skill to teach in undergraduate education. However, these Retrospectives are timeboxed meetings moderated by the ScrumMaster, and there are simply not enough scheduled contact hours for me to hold honest Retrospectives with every team. More specifically, in a 50-minute meeting at the end of a Sprint, we won't have time for a multi-team Sprint Review and individual team Retrospectives if I am required at each Retrospective.
The next option is that one undergraduate on each team could take this role. The main problem here is that I don't image this role shall take the 10 hours per week commitment that I am asking of all the participants, and so the student in the ScrumMaster role would also be a part-time regular team member. The biggest risk, pointed out by Clinton Keith in Agile Game Development with Scrum, is that "the team assumes the role is a leadership one, [and] they defer ownership to the ScrumMaster" (p.51). This would be disastrous: I have been in learning experiences where students lost the sense of ownership over the project, and this destroys morale and productivity. The advantage to this approach, however, is that each team could have a 15-minute stand-up at the start of our 50-minute slot, and that leaves 35 minutes for other activities, such as Scrum of Scrums or Communities of Practice meetings. As Product Owner, I could float between teams during the stand-ups, and we would not be limited to three teams. This also frees up the schedule at the intersprints so that the Sprint Review, team Sprint Retrospectives, and Sprint planning can all move forward within the alloted time.
One may immediately and justifiably raise the question: how will I know if an undergraduate is qualified to be an effective ScrumMaster when so many of the requisite skills are unmeasurable? My answer is somewhat pithy: I'm not sure if I am a good ScrumMaster, so we may be no worse off! This also raises another important question: would any undergraduates signing up for a "Game Programming" class actually want to do this? Clearly, I would need to know the answer to this question well before we started any sprints! For those of you who may be wondering about the curricular implications, don't worry: I designed the syllabus in such a way as to promote this kind of project-based learning, in which students specialize in certain areas and experience the rest through legitimate peripheral participation.
A third option involving only undergraduates is that I could have one or two students who act as ScrumMasters for multiple teams. Keith suggests that a ScrumMaster can handle two to four teams. If I had one ScrumMaster per two teams, then 30 minutes could be devoted to stand-ups during our 50-minute slot, and that leaves 20 minutes for other activities. I could still float among teams as Product Owner, and the student ScrumMasters would not need to be developers on a team. Ideally, then, these undergraduate ScrumMasters would be putting in the same time as their developer counterparts.
There is a fourth option that brings in a few extra people. It so happens that I have two graduate students who have asked if they could work with me in the Fall. I suspect that both had research-oriented programming projects in mind, but potentially, I could tap one or two of these to be ScrumMasters for graduate credit, and I could have them document their experience in a technical report. If I had both and no more than four teams of undergraduates, that brings us to two 15-minute sprints and 20 minutes of miscellany during a 50-minute scheduled time slot. Also, being graduate students, and all else being equal, they may have an easier time learning ScrumMaster techniques by reading about them. However, I do not know if any grad students are actually interested in this, and I assume it goes without saying that I cannot afford to send anyone for real ScrumMaster certification.
It has been useful to me to write out the details of these four options, and I hope you, kind Reader, have enjoyed the exposition. I hoped that one of the solutions might outshine the rest as I wrote this, but I am still uncertain. I welcome your comments as I consider my options.