I teach various physics classes in a high school in the western suburbs of Chicago. I also advise our Science Olympiad team on physics and building events, mentor our Robotics Team as they compete in the FIRST Robotics Competition, and keep an eye on our Physics Club.
Historically, my AP Computer Science A students have struggled with the concept that the value of a variable in Java can be a reference to an object. Actually, even before I started teaching APCSA, students would find me the week of the AP exam and ask for help on this concept. Over the years, I’ve improved both my instruction and student understanding in several ways. I’ve utilized tools like BlueJ’s debugger and the Java Visualizer to help students see the relationship between these concepts. I’ve created practice programming activities that create the cognitive dissonance necessary to spur reconsideration of understanding. I’ve woven these concepts throughout the curriculum to provide students with multiple and increasing complex opportunities to explore these relationships. Finally, I’ve tried to keep my language purposeful, precise, and consistent as, too often, we refer to variables as if they are objects. Despite these actions, students still struggled with these concepts. Last year, I had a new idea, and this year I implemented it.
I decided that these abstract concepts are further abstracted by the computer, and that’s too much abstraction for students at this point. Therefore, I removed the computer, and we explored these concepts via an extended analogy in a CS Unplugged manner:
variables are represented by small sticky notes
objects are represented by full sheets of paper
full sheets of paper are numbered in their upper-right corner; these numbers are references
Variables When a variable is declared, a new small sticky note is used and the variable’s name is written on the top of the sticky note. The value of the variable is written below the name. There isn’t a lot of room on a small sticky note. There’s only enough room for values that don’t take too much space to store such as primitive values and references to objects. You cannot write all of the properties of a Turtle object on a small sticky note! When the value of a variable changes, the previous value is crossed off, and the new value is written.
Objects When a new object is created, a new sheet of paper is used. To keep track of all the sheets of paper, they are numbered in their upper-right corners. The name of the class of the object is written at the top of the sheet. The names and values of the object’s properties are written below the class name. There is plenty of room on a full sheet of paper to write all the properties of a Turtle object. As the value of an object’s property is changed, the previous value is crossed off, and the new value is written.
References References are the numbers on the upper-right corner of the sheets of paper. They are used to find the desired sheet of paper from among all the sheets of paper. When a variable is assigned the reference to a newly created object, the value of the variable is the number on the upper-right corner of the new sheet of paper for that object.
Methods When a method is invoked on a variable that references an object, the value of the variable is used to find the desired sheet of paper. Once the sheet of paper is found, the method can operate on the object by potentially changing the object’s properties by updating a value on the sheet of paper or returning a value.
In one lesson, I modeled this extended analogy for the class in the context of a simple example involving two Turtle objects, two variables that reference Turtle objets (turtle1, turtle2), and two variables of type int (number1, number2). In the next lesson, pairs of students, with my assistance, traced through a couple of other examples using small sticky notes and sheets of paper.
Based on a short formative assessment, student understanding appears to be improved compared to previous years. I will continue to use this extended analogy as we revisit these concepts throughout the year. I may extend this analogy when students start implementing their own methods to include a paper form that represents a method invocation. Values are copied to complete the form. When the form is returned after the method returns, the returned value is copied as well.
A couple years ago, I wrote about a new course that would be offered in the 2017-2018 school year, Software Engineering. Last school year, the course was a great success, although there are many refinements I’m preparing for this upcoming school year. The second semester of the course is described as “small groups of students develop a software product as they iterate through software engineering development cycles to produce a software product”. Other teachers expressed the most interest in how to facilitate teams of students managing a semester-long project and how to assess them throughout the semester. Until last semester, I had never done this as a teacher. Fortunately, I remembered that I did this every day in my previous career as a software engineer.
One of my roles in my previous career was that of a methodologist with a specific focus on Agile Methodologies. After a review of the current state of Agile Methodologies, I decided that Scrum would be a good fit for my students. None of these students have any experience with Agile Software Development, and few have worked as part of a team on a substantial project. Scrum provided sufficient structure while maintaining the lightness appropriate for small teams. The activities in each sprint provide the opportunities for everything that is needed in project-based learning: planning, review, and reflection. I attempted to fulfill the role of Scrum Master. Each team had a product owner who was external to the class.
I scheduled the teams into four, staggered, 4-week-long sprints. While all teams started and ended their project based on the start and end of the semester, the first and last sprint for each team were of varying length such that I could facilitate the activities with each team during class.
The key activity in Scrum is the Daily Scrum or stand-up meeting. Teams would hold their Daily Scrum twice a week. Having a four-week sprint seems long, and holding a Daily Scrum twice a week seems infrequent, but these teams aren’t developing software as a full-time job; they are in class for 50 minutes a day. At the beginning of the semester, I would facilitate every Daily Scrum meeting in my role as Scrum Master. Soon students became adapt and comfortable, and teams held their Daily Scrums while I observed from afar.
We focused on four activities in each sprint: Sprint Planning, Story Time, Sprint Review, and Retrospective. For each of these, the team would assign a student responsible for facilitating the activity, capturing the work, and sharing it with the team. With a team of four students and four sprints, each student would facilitate each of the four activities throughout the semester. The student facilitating the activity was assessed based on the student’s effectiveness in facilitating the activity, their demonstrated understanding of the activity, and the quality of the submitted document.
Repeated feedback is essential for both project-based learning and software development. Teams would receive feedback from their product owner during each sprint review (and more often as needed). Teams would receive feedback from me and each other during each retrospective.
In addition to these standard Scrum activities, I added an additional activity at the end of each sprint, a personal retrospective. Each student would evaluate themselves based on their role as a Scrum Team Member, reflect on the personal goal they set in the previous sprint, and set a new personal goal for the next sprint. Based on student feedback, for the upcoming school year, I will also have students evaluate their teammates.
At the end of the semester, we hold a Demo Event attended by all the students, their product owners, and other stakeholders. Each team presents their product in a modified version of the “3-in-5” presentation format. After the Demo Event, each student completes a final retrospective reflecting on the entire semester.
This structure worked well for my students and their projects last semester, and we will use the same structure next year with some refinements.
One final note – Scrum is used for all kinds of projects; not just software projects. After my experience last semester, I would encourage teachers to consider Scrum as a tool to facilitate any project-based learning of a significant duration.
Questions? Comments? Please comment here or each out to me on Twitter.