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:
Much rambling follows.
ReplyDeleteWith all you’ve written about the class and students, and knowing my own son and some of the students who are taking the class, there’s something I’ve noticed about them: they “think differently” and “learn differently”. I’m not quite sure where I’m going with this, but GCD brings out that “thinking differently” and allows them to flourish. Maybe it’s the independence. Maybe it’s the expectations. Maybe it’s the lack of definition and step by step instruction. It’s probably all of these.
There’s a spark in these kids that they don’t get in other, traditional type classrooms and learning environments. Could it be the ambiguousness of the class, even with a well-defined goal? And by that I mean the ambiguousness of the methods to reach the goal. The students know what the expected end goal is, and they’re for the most part figuring it out as they go, in order to reach that goal. They’re learning by both success and failure. There’s no recipe here. No rote learning. And for some things, there’s not even a method. They’re inventing it themselves!
These are “think differently” kids that have managed to survive and thrive in a largely traditional approach to education. It’s changing rapidly, but still very similar to the last 150 years. Many kids don’t thrive in that environment, and either through not learning that way, or from pure boredom, end up with low grades or act out inappropriately.
I’m wondering how we might use this class to reach more of these “differently thinking” kids? Not only in BHS, but ZED as well. I’ve got to believe that ZED is full of kids that don’t learn by traditional methods, or were so bored they acted out and ended up there from their home school as a result. Has there been any outreach to ZED about this offering? Perhaps this type of learning might benefit them?
I believe a mix of kids that both thrive and fail in the traditional model will thrive here.
Interesting observation -- I hadn't thought a lot about the level of "different" present in how they are asked to think. As a teacher, I see a lot of the other side of it when students struggle with ambiguity and disengage. Nate is in an ideal project right now -- I am providing him with readings and structure, but he is left to go through the design process and create his own outcomes. He is also experimenting with game solutions from scratch without options. Students on highly technical teams are getting frustrated with how difficult some of their tasks are and how much they are left to do their own troubleshooting. Software is just really really hard.
DeleteAs for ZED, the main challenge I imagine is a lack of prior experience to jump into tasks. Most GCD students have at least some background in CAD, electrical work, fabrication, or other relevant topic areas. This lowers the barrier to entry, but I'm not sure what factors enable students to stick with a hard problem long enough to figure it out. In its current state, engagement and structure are both too low to support many students. I'm hoping that future iterations will have a lot more of both, making it more feasible for a ZED group to engage.