This follows up on my epic post from earlier this week. I did indeed continue the theme of Mob Programming in Wednesday's class meetings, although I decided to skip the game entirely. Instead, I began each meeting with a recap of the strengths and weaknesses of Monday: they had learned the fundamentals of Mob Programming, but there were ways in which the game got in the way of the task at hand. I also shared with them my observations that they were trying to act like race cars rather than bulldozers and, in so doing, abandoned the values of TDD and Clean Code, which are the actual topics of the course. We kept the context of FizzBuzz, but we started again with a fresh project.
We used mobti.me once again but with only the two default roles, Navigator and Driver. I was unable to acquire a wireless keyboard in time for us to sit in a row and pass it down, so I copied the same series of names to the whiteboard as we used in the app. This way, students knew when their turn was coming without our having to go to the app's browser window first. I also ensured that audio was working properly before we began.
Another notable difference was that, believe it or not, I had fewer students in both sections on Wednesday than I did on Monday. I had expected the inverse, that those who skipped Monday would hear that there was something really interesting and engaging happening and that this would bring them back to class. (Insert laugh track here.) Instead, the Section 1 had only five attending students, three of whom had been there on Monday, and Section 2 had six attendants, five of whom had been there Monday. The new students looked a little intimidated, but it did not take long for them to integrate into the process.
Both groups got much farther into the project than they had before. Three factors seemed to contribute to their success: they had experience now with the problem (as Fred Brooks said, plan on building one to throw away, because you will anyway); they had experience with mobbing; and I had frontloaded to them a strong reminder to use TDD rigorously. We got through two complete rotations in the first class with time to discuss the experience at the end. We got through almost two rotations in the second class, but I cut off the last Driver-Navigator pair so we could share some conclusions. Between rotations, we took a few minutes to talk about how it was going.
In Section 1, they ran into two categories of problems. One was that the Driver sometimes acted as de facto Navigator, pushing their own vision rather than the mob's. Put another way, the Navigators still tended toward passivity rather than active navigation. We got to talk about this at the end of the class meeting, and I think the students got to a better understanding of this role. The other problem was slipping out of the Red-Green-Refactor rhythm, doing things like refactoring while writing a failing test, or going from passing tests to defining new tests. I shared my observation of this at the midpoint, and there was marked improvement in the second rotation.
Section 2 was more able to hit the ground running. Various members of the mob held the team accountable to TDD in a more consistent manner. A few Navigators also engaged in improvised dancing while waiting for tests to run. Hey, why not? This group was clearly having some fun with it. They ran into a few problems with failing to meet naming conventions for test names, and toward the end, they headed down a path that would be fruitless, as they tried to factor out essential parts of a method: that is, they would have ended up factoring out every piece into a new method that does the same thing. I tried to help them see that the root problem seems to have been that they started working on a solution (adding a new method to handle something) without really agreeing on what problem they were trying to solve.
During the midpoint discussion with Section 2, a student pointed out that the mob "butted heads" over an issue of how to move forward. I smiled and told them that, back in my day, we just called this "having a conversation." Indeed, that's all it was: a group trying to determine which of two ways to go. It was interesting to me that the students saw this as some kind of competition ("butting heads") rather than the kind of formative argument we should be actively engaging with all the time in higher education.
I am very glad that we spend a second class period exploring Mob Programming. Although neither group fully completed the FizzBuzz problem, they got far enough in to see how a mostly-functioning mob should work. That is, I think it modeled the process sufficiently that a team could take this into their own project work, and crucially, I laid the groundwork to be able to use this in teaching my upper-division courses next semester. I definitely want to add this to my usual arsenal of CS222 tools, although I am not currently in the schedule to teach the course next academic year. That is, indeed, one of the reasons that I have written these posts, so that I can refamiliarize myself with these ideas later.
I am left with the question of whether playing the Mob Programming RPG first was truly necessary. It was useful for me, as someone who has never taught this technique before, to have something to deploy out-of-the-box. However, now that I've seen it in action and spent hours thinking and writing about it, I suspect that I could just start with an exercise like today's. It would be an interesting research study to conduct, although I am certain that the more guided experience a student has with Mob Programming, the better they will understand it.
No comments:
Post a Comment