I'm excited to be able to teach my Spring Game Studio course this semester, even if it's not ideal. The ways in which it falls short are that we cannot use the actual studio space due to physical distancing restrictions, the time it's offered was determined by the college rather than the department and is terrible, and it's almost all Computer Science majors--in part because of that awful scheduling that prevented our being able to synchronize with the other majors that regularly send students. That said, I am very grateful to have about a dozen eager and excited students, and I am able to continue to explore how to manage multiple simultaneous teams. When it comes to distributed work, we can be more intentional about it than we were when the Spring 2020 studio had to suddenly change character due to the pandemic.
The Spring 2021 studio started with six different game ideas, and it took us until the fourth week of the semester to narrow it down to just three. This process involved building MVPs that were valuable in explaining the games and building teams around them. I wrote up a methodology for distributed development, based on my notes from last year, and that is currently available on GitHub.
On Friday of last week, all three teams met together so that I could talk about the planning and production process. This was designed to help them bridge the pre-production work and prototyping they had been doing to get us into the expected rhythm and rigors of the methodology. I showed them how we could use HackNPlan to manage parts of the project, and conveniently, I was able to use the context of one of the abandoned projects: it was something new and unbuilt and yet still familiar, which is much better than talking about re-engineering something that already exists.
This allowed the teams then to come to our Monday meetings and plan their projects. Here, however, is where I think I made a mistake. I had hoped that they would be able to articulate their features as user stories, then break them down into tasks, and then assign tasks during the meeting. Even though I knew how hard it was to turn ideas into user stories, I don't think I gave them enough time here. When I am leading an immersive learning team, I will often just do this for them, based on their discussions. The result was that it took well over an hour for each team just to figure out what a few of their stories are, let alone the problem of prioritizing them, committing to them, and planning the work required to satisfy them. The meetings went too long, with the concomitant fatigue.
I think I could have handled it differently. One option would have been to schedule separate meetings, one for story identification and one for sprint planning. This also would have given me a chance between meetings to give feedback on story articulation, whereas what I had to do on Monday was traipse between three different online meetings. An alternative would have been to allow the teams to designate one or more team members who would devote their time to the story identification. That is, they may have served as I have done in a Product Owner role.
I'm still happy with the work they have done and proud of their progress, but I wanted to make sure that I tracked this idea here on my blog so that next time, I might remember to separate these processes. Also, the methodology (as of this writing) mentions Trello as an option, but I had forgotten that Trello does not allow for convenient separation of story articulation and commitment vs. task articulation and planning. I should simply remove it from the methodology next time, because it does not allow for the precision that I would normally have on the studio's whiteboard. Unfortunately, I learned this lesson because one of the three teams tried to use Trello and then broke down in their planning meeting when they couldn't follow the steps I had shown in the previous meeting.
No comments:
Post a Comment