Some time last semester, my chair asked if I would teach a section of CS691, a new graduate course for my department's Masters of Science in Software Engineering program. The course is titled Software Requirements and Design, so right off the bat I was a little put off by the sheer waterfallness of it. I have been mostly uninvolved in the MSSE program, which struggles to get started for various reasons. Be that as it may, requirements and design are definitely concepts in my bailiwick, so I agreed to put together the best course I could. He told me to expect relatively low enrollment, given the low number of students in the program, but we had to offer it anyway because these students need it to graduate.
As I was procrastinating designing the course, I received a call from my friend Kate who is working with a local non-profit, ecoREHAB. She's leading a team of students who are revising the organization's marketing materials to help ecoREHAB better explain its mission and values. Working with their board, she had some ideas for potential software products to help. This aligned very well with the learning objectives of CS691, so we agreed to a collaboration. I didn't yet know how many students I would have or what their background was, but ecoREHAB was very understanding of this: though I couldn't promise a product, I was sure we could build a prototype, and that would be enough that we could see if it was worth pursuing to production or not.
This brings us to the point of the blog post: yes, once again, it's story maps! I decided to use this technique in CS691 to capture and track high-level requirements, and so I assigned Patton's book as required reading. With my plans in place, I awaited the start of the semester. Turns out, I only have three students in the course, two of whom need it to graduate and one who is taking it as an elective. During the first week of the semester, we read the first few chapters of Patton and completed his "morning routine" story map, where a team builds a story map of what they do in the mornings. The argument in the book is that people already know how to make story maps, they just need to learn how to do it in a disciplined and pragmatic way. This exercise went well, although the students pushed pretty heavily toward making a taxonomy rather than a map. That is, they wanted to classify and make categories rather than focus on discrete stories. I pointed this out, and we moved on. We made a second story map, based on a straightforward problem a friend of mine had last semester: he wanted to know which courses the faculty in his department wanted to teach or did not want to teach, and have that information readily available when scheduling. Here, too, I don't think what we came out qualified as a "story map" as defined in Patton's book, or at best, it was an awkward one. I pushed the students to think about this, but they believed it was satisfactory. We put these "starter" maps aside as we spent the rest of the month in a kind of race through background books, papers, and ideas. According to the schedule I had laid out, by early February, we would be returning to our community partnership; I figured we would come back to these issues then.
During our month working together, I came to truly respect my students. Part of it may be the small class size—there's nowhere to hide, and everyone gets to speak their piece. Regardless, these three are excellent students: they keep up with all the readings, they ask great questions, and they voice and justify their opinions. One has industry experience from overseas, one has local small-team experience, and one comes directly from undergrad and a masters in another discipline. I don't think I could have picked a better mix of students. I say all that in part to qualify my comments below: I have no doubt that these students are doing their very best.
I decided I wanted to give the reins to the students when we did our planning meeting with members of the ecoREHAB board. To bridge our background work to the project, I did another story mapping session. I'm working from memory now, and I don't quite remember the context I picked, but again, I felt like there were pieces that the students just weren't getting, like sliceability and the difference between an activity and a category.
This took us to our big meeting with the community partner. A student volunteer led the session, and he did an admirable job for a first-timer. It's easy to forget that this stuff is hard, just simple things like keeping people on track during a meeting, welcoming different perspectives while being mindful of the time. Also, we have no courses that help students with this kind of process; if I were to teach this course again, I would put some of this into the course description, since where else would students get the chance except when studying requirements gathering?
One of the team could not make this meeting, so we recorded it. This proved to be quite useful, since the team agreed that our one-hour meeting with ecoREHAB could not have possibly produced as rich a story map as we wanted. I challenged each student to make their own story map, reviewing the recorded video as needed, and we came together in our next meeting to share what we had found. I kept my Socratic composure as I pressed the students to evaluate their and their peers' maps. They had differences of course, yet they were still pretty confident... but I was not. In an inspired moment of which I am rather proud, I decided not to tell them what I thought was wrong; instead, I assigned them an essay, to return to Patton's book and then to think and write critically about what they know about story maps and how they know it. This was on a Friday, so I tried to put my own concerns on the back burner until we could get back together.
On Monday, the first student I met in the hallway shook his head and said something like, "That damned essay." He proceeded to tell me how much he disliked it because it forced him to realize how much he didn't know. I tried to turn that ship around and tell him that this means the essay worked! As I was doing this, the second student came in, muttering with half a smile, "That essay..." As you might guess, all three students came in a bit dejected, but I think much smarter than when they had left on Friday. All three wrote brilliant essays about what they thought they knew, and about how they realized that their assumptions were wrong. We had an excellent discussion about this, including trying to think of factors that led them to believe what they now had come to doubt. I was joyful to see them begin to dissect the differences between a story map and a hierarchy. We talked about sliceability not as a requirement of a map but as a property of a well-designed map. Perhaps most critically, a student voiced a real concern: if this technique was so hard to learn, was it worth it? For them, of course, it's an open question. For me, who had also made mistakes in my first attempt to learn the technique, I have already paid the cost of learning and reaped the benefits in my studio class. It will be interesting to see what happens to their skepticism as we move forward with our project.
That led us to the real problem: what do we do about this community partnership, given how much trouble they had already had? We agreed that I would make a story map to the best of my ability and we would start into the project using that one. This would give the team the opportunity to work with a reasonable map (I'm still learning too, of course) and reflect, particularly after an iteration is complete, on the impact of this technique. I made the map, with some student input, on this past Monday. We were sure to include conditions of satisfaction with each story, as I wrote about before. but then I headed out to a conference and, after that, Spring Break week. I expect to write about what happens in the back half of the semester later.
No comments:
Post a Comment