Deliver Learning Frequently
"Deliver meaningful learning frequently, from a couple of days to a couple of weeks, with a preference to the shorter timescale."
How long can we go without knowing whether students have learned anything? Quite a long time in the traditional model of schooling. Think about those six-week-long units on a classic novel or one of those semester-long research projects. If teachers are looking only at final work, they have no way of knowing what's happening and what isn't.
This is where Agile's notion of sprints, daily stand-up meetings, empirical measurement, and rapid iteration are important. A sprint is typically a two-to-four-week period of time during which a specific set of functionality will be added to a project. It could also be a unit with specific learning goals.
But we don't just wind it up and let it go; we check on it every day through a meeting called a "stand-up" that is often a daily part of the Scrum process. Whether or not every person has to actually stand up is not important. What matters is that every person answers three questions: (1) What did I do yesterday? (2) What am I doing today? and (3) Is there anything stopping me from getting my work done today?
This last question my be the most important. The person in charge of the meeting (sometimes called the "Scrum Master") will work to remove any impediments to another person's success. In the classroom, the teacher can do exactly the same thing. If a student needs help with something, or just doesn't know what to do next, a brief conference during work time is usually all it takes to back on track.
In general, shorter sprints with fewer goals are preferred. Why? Because each sprint is its own iterative learning opportunity. The more iterations we go through, the more opportunities we have to achieve success. Failures, should they car, are small and easily recoverable.
If our goal is to deliver learning frequently, challenging ourselves to produce results in ever shorter but still reasonable periods of time is essential.
Putting definite start and end dates on things is called "time boxing" in Agile. Within each "time box" (the word is also synonymous with sprint), we commit to delivering some form of meaningful learning, preferring shorter time scales to longer ones.
Discussion
Add your feedback below. To keep track of who is saying what, use an H1 tag (a plus sign "+" in the edit window) to identify yourself. For example:
Steve Peha
A fantastic example of the power of increasing iterations by shortening cycle length came to me from Shelley Harwayne, teacher, author, and principal of the somewhat famous PS 291 in New York City. At a conference, I asked her how many pieces of writing her students published each year. About 40, she said.
I was shocked. That was about twice as much publishing as I was doing—and I was already going faster than anyone I knew. So I asked her how such volume was possible while still keeping quality high (the writing samples she showed were better than anything I was getting at the time). To which she replied with the best possible advice: "Just publish more shorter pieces."
This made immediate sense. By shortening the length of the pieces, we would get through the writing process faster. Each time through, we would learn something new—sometimes several somethings. Kids, especially the little ones, only have so much stamina for the hard part of writing like revision and editing. Shortening their pieces meant higher quality work over a smaller volume of text in those crucial areas.
In Agile terms, all we were doing was tighter time-boxing or having shorter sprints with less "functionality" or fewer learning goals per writing cycle. The end result was always represented by the same thing: a complete piece of writing. And with each piece a student produced, there were opportunities to work on new things and deliver new learning.
This idea of always delivering "working software", or in the case I mention "finished writing", is very important. In the old days (circa 1985 or so) most software was built in pieces and the integrated at the end. Integration could be a nightmare as often the pieces, having been developed separately, didn't play well together. So the concept of "continuous integration" was developed. The idea was to deliver a working product with all available functionality up to that point and with all components integrate into the whole.
This is exactly the difference between teaching kids isolates sub-skills and then hoping they can "integrate" those skills into a real-world task like producing an entire piece of writing. "Continuous integration", or as we call it in education "teaching skills in context), works better. But the key here is rapid iteration. If we don't give kids enough cycles to learn the skills in context, their "products" will always show "defects" just like many software products do.
Perhaps the best part of my change to shorter cycle times is that the kids were producing so much work, I could learn a lot about them. And because iterations were so short, it was very easy to apply learning from a previous piece in a new piece.
Sure enough, as Agile implies, the more iterations, the greater the learning. I have found this to be true in every subject and at every grade level.