To start the year, every student wrote a letter about themselves, their future, and the course. This letter was based on Ben Zander's concept of transforming relationships and giving every student an A. In the letter, each student gave me the insight I needed to start a successful working and mentoring relationship with them. As first drafts, nearly every letter came in looking awful. To address this, I started with comments and suggestions over Google Docs. For some students, this was all that was needed to lead to a more productive draft. For others, I found myself having one or two 1:1 meetings at lunch, during advisory time, or after school to verbally probe into some of the questions I wanted them to explore. I also reached out to my English teacher colleagues who were amazing in helping me and my students through the writing process.
Once a letter was accepted as complete, I used it to match the student with the best-fitting mentor I could think of. Every student is paired with their own mentor, a professional engineer or designer chosen from my college and local friends who were willing to jump in. I don't know if my students realize how top-notch these people are yet, but they will in time. One mentor, after receiving his mentee's introductory letter, even wrote back with his own letter, written as if he was in high school but then continuing to the present day. As I see some of the email exchanges that I am CC'd on and poke my head into some of the Skype chats during class, I can't help but get excited for all the things students will learn from NOT me this year. As I get texts and emails from mentors seeking additional advice and counsel on how best to help their student, I am amazed at how much these people care about a group of random kids in Byron, MN.
Our Grand Challenge for the first quarter was not the individual work, but the team effort that was required to build up the course. After getting a sense of what students were interested in doing, I divided the class into teams of 2-4 with different areas of focus. From there, I presented the core of the vision to the class: this quarter, we were going to get our game built and ready to play and improve our classroom to be a fun and effective learning space. I structured this into "OKRs", or "Objectives and Key Results", a goal-setting and measuring format created by employees at Google so that everyone could have autonomy while moving in the same direction, have clarity of what they and others were focusing on, and have a system to measure their own progress. I asked each student team to do the same. Here are a few example OKR docs from the teams in class: CNC team, NodeJS team, Rules team.
At this stage, my role involved checking in with each team each day to offer ideas, direction, feedback, or whatever was needed. I also made sure that the different groups were communicating with each other. At first, this process seemed relatively successful. After a month, I found that teams were splitting two different directions: the teams that had long-term projects did okay managing their day-to-day work productively, but the teams with many small tasks had a hard time figuring out where to go next without heavy support. To address this, I introduced three elements of the scrum framework: a product owner, a Kan Ban board, and a daily stand-up
Scrum is used heavily in the software world as a way to help teams self-organize and complete tasks around user needs. The role of a product owner is to decide which tasks need to get done, and what "done" looks like, to achieve the objectives of the company. As the lead person pulling everything together, I was a product owner. However, I also invited one student from each team to take on that role and work with me to generate and refine their team's task list. From here, each team put the tasks on a large kanban board divided into four sections: backlog, in-progress, ready-to-check, and done. The backlog includes all of the tasks that need to be done but had not been started. In-progress is what you would expect. Ready-to-check includes all tasks that the doer thinks is done but needs a product owner to review to make sure it truly meets the definition of done. "Done" is truly done.
We used the board as part of the daily stand-up meeting. Within the first five minutes of class, the entire class crowded around the board and said (1) what they accomplished yesterday, (2) what they were planning to do today, and (3) if anything was blocking them. (1) was for public accountability -- I only realized after we stopped doing these daily meetings how well that was actually working (a few students slipped into multiple unproductive days without this). (2) was for me -- if they said they were doing something, but it didn't sound very useful or sound like they knew what they were talking about, I would either correct on the spot or follow-up with that person after the meeting. (3) was for everyone else to listen to -- if two teams were going to be doing something in the same space or with the same resource, they would have a heads up and be able to work it out ahead of time. This didn't come up a lot during the time where I used the daily stand-up with the entire class, but now that we are closer to fully integrating everything, it seems more likely to happen. I plan to return to using this whole-class meeting daily in Q2 on team days.
Back in August, I pictured the game starting up in a couple weeks after school started. It was only after a couple weeks passed that I realized that my sense of reality was heavily warped. The most obvious challenge we faced was finished the game board surface. Doing so required the use of a machine that we bought in isolated components and assembled ourselves. A former student and older brother of a GCDer led the design, assembly, and software setup for the machine. Unfortunately, the challenges involved in making everything work were more than even this mentor could quickly master. The two students working on the machine, with some weekend help from their mentor, found faulty limit switches, a bad stepper motor, wiring issues, and software configuration problems. Then they went through a time-consuming process of calibrating the machine so that a software inch would be a true inch. To actually cut material, they first needed to design a part in CAD (something they knew well), but then needed to run it through CAM (computer-aided manufacturing) software to tell the machine how to make the part. They needed to figure out which bits to use and how fast to spin them. They needed to find a consistent way to mount the stock wood in the machine so it would remain steady. They needed to find a way to mount a shop vac hose to the machine with a dust-trapper so that the excessive amounts of sawdust would stay contained. And this is not a complete list! Though this team dealt with the most extreme set of challenges for what sounded like a very simple task, nearly all teams found themselves experiencing dozens of complex problems nested within something that sounded straightforward at the beginning.
I love watching students work through this kind of challenge. Given that I am used to students giving up on tasks with lots of direction, resources, and a knowledgeable guide, seeing students persevere with none of these is refreshing. Here are a few action shots from the semester as students persevere through this (thank you, Kris Nelson!):
Finally, I asked students to end the quarter with a video summary that they would share with me and their mentor. This video had to be at least two minutes long and discuss what they did and what they learned. Watching these has been a ton of fun for me since I sometimes forget where students started the quarter. Thank you, Jen Hegna, for recommending that I do this! A few examples are below: