If you’re like me, you get a special satisfaction out of pronouncing “processes” like “processEEs”.  In that case, you are awesome.

Yes, it is late, and yes, I spent all day trying to incorporate a Google places details search over my Google nearby places search while learning about Casper.js testing, modularizing and objectifying (sorry, couldn’t help myself there) code, in addition to using the Google autocomplete function after sprinkling on some regex to validate user input although I still want to go in and run all input through some escaping a la OWASP recommendations but let’s face it, I need some metaphors, and teaching and programming are a great combination.

So, back to my topic: teaching is an agile process.  Let’s take a look at agile and what that entails:

Quick turnaround.  Instead of creating a finished, “perfect” product a long time from now, create the project in “sprints” (stages) and check in with stakeholders after each stage.  That way, it’s easy to incorporate feedback before the next step.

It feels unnecessary to even explain how that’s like teaching, but let me spell it out anyway.  In teaching, you must teach a class at a certain time.  If you don’t have a “perfect” lesson planned (and you never do – that’s the dangling carrot that keeps you up at night and working on the 4th of July), you must teach anyway.  And your “stakeholders” will give you feedback immediately (both non-verbally and verbally, not to mention on assignments and tests later on) on how lacking your lesson planning is and where to improve.

In agile, you can make small changes immediately in response to feedback.  You might even adjust features and perhaps alter your overall course.

In teaching, if your class is feeling lackluster, you can change your plan in the moment to a different activity.  Not only can you, but you must.  Or, if your class is not following your carefully-planned content, you must change your plan accordingly.  You cannot wait two months.  You must do it now before Jim falls asleep, Sally starts texting, and Bob asks an off-topic question.  If you realize the next day that what you had planned to to on Thursday is not what the students actually need, you must change your goals for the week.

Although maybe it’s not specific to agile, test-driven development is a big deal (again, it’s late, forgive my lacking vocabulary).  This means that you write tests and expectations, followed by actually writing code. This is an awesome concept that mirrors teaching.

In education, assessment is all the rage.  And with good reason – there must be some way to “measure” the black box of the human mind and learning. Yes, I will continue to use “” with “measure” because obviously there’s NO way to measure learning empirically, but we do our best to get a rough estimate, notwithstanding affective filters, investment, hunger, temperature, relationships, money, daydreaming, rectangle-gazing, parents, children, landlords, boredom, depression, cold, rain, snow, sun, lightening, dirty classrooms, raccoons, religion, gender, clothing, food, bedbugs… yes, these are all things that affect student learning and assessment accuracy.  And yes, these are all things that have distracted students in my classroom.  I’m especially proud of the raccoon.

Finally, in agile your client is not always aware of what it is they need and what exactly you do in order to produce their result. Same in teaching – when students complain of one hour of homework, they don’t realize the dozens of hours you will spend grading said homework.  Also, students often think they want to do one thing (watch a movie, do fewer presentations, take more multiple choice tests) when in reality a teacher knows a better way to get them to their goal.  And when students endure an activity or lecture, there’s little realization of the time and effort put into preparing that.

I’m certain there are more parallels to be drawn, but for now there are more Google APIs to be discovered.