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.
Thanks for sharing your blog post on your design choices here. Was scrum a positive experience your teaching? I work as a scrum master professionally... I'm really interested in learning how scrum works in project based learning.
ReplyDeleteDo you have any lessons learned from the experience?
Since this first experience, I've been careful to work with only smallish-teams, no more than 14 students at a time. This really simplifies the project management, and predictably, the best results have been from working with the smallest teams.
DeleteI've settled into a pattern that works locally, in which I serve as a combination of Product Owner and Scrum Master. This doesn't really confuse the students because they have no experience in "real projects for real clients" anyway, but it does mean I have to adapt a few practices. I manage the product backlog personally (or with my collaborators), and then I facilitate sprint planning meetings to help the team identify their tasks.
Frequently, their impediments are matters of inexperience---sometimes second-order ignorance, where they don't know what they don't know. In these cases, to remove the impediment, I have to design an intervention, which is frequently a short workshop, design session, or simply pairing up with them.
I have found that the best results come from cases where I can frequently work alongside the team, which means I have to balance Product Owner, Scrum Master, and Team Member roles. From a theoretical point of view, I think this works because I can model behaviors in a community of practice: the team can see me--the expert--and how I engage with the problem, and this provides a framework for them to approach their own problems. I'm still trying to find the best balance here.
Is it _really_ Scrum, or just something Scrum-like? I've thought about the question, but I keep coming to the conclusion that it's pedantic: we get productivity and learning results, which is all I really need as both a mentor and a instructor.
One of the best aspects of Scrum (or Scrum-like) is that it authorizes the team to take ownership of the project. This has been a challenge for every team I have worked with, since undergraduates are used to a model where someone else hands them tasks to do. Turning this on its head forces the students to think through design spaces, to collaborate on solutions, to consider tradeoffs, and to accept responsibility for successes and failures. As a professor, I have been very happy with how this leads to both intellectual and emotional growth, and the evidence so far is that employers strongly value this kind of learning. Many of the students in these project-oriented classes have landed excellent jobs, and discussion of these projects tends to dominate interviews.
Thanks for posting, and I hope this addresses some of the issues you were wondering about. Please feel free to seek clarification. I'm still honing my practice, but this current approach seems to work well.