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.

If you are interesting in a succinct overview of Scrum, I highly recommend the book, Scrum: A Breathtakingly Brief and Agile Introduction by Chris Sims and Hillary Louise Johnson. (If you want more, their book The Elements of Scrum is also excellent if the first book leaves you wanting more.)

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.