A Sprint Parable
The Beaner is in fourth grade now. His teacher assigns homework nightly rather than weekly, and there are lots of rules. One of his nightly assignments is to read, and to note the book title, author, genre, and level—Easy, Just Right, or Challenging. He has to read so many minutes a night, across at least 8 different genres over the course of the quarter, and at an average reading level of Just Right.
After a couple weeks of school (during which Al signed his homework and reading sheets), I happened to look at his reading log and review the rules in the course of clearing the dining room table of papers. All the books listed were Easy ones. So the next time the Beaner and I were out walking, I said, "How come all the books on your reading log are easy ones, when one of the goals is to read Just Right books?"
He replied, "Because a 'Just Right' book would be something like Harry Potter and the Deathly Hallows, and that would take me days to finish."
I explained that the object was not to read a book a night, but to read a Just Right book for as many nights as it took.
I don't often talk about work here (or mostly haven't in the past), so anyone who might still be coming by in hopes of an update after a year or more of silence might not notice the parallel with "sprint" culture as practiced by many teams who think they're being agile or "doing Scrum." In Scrum there is a notion that each user story/feature/unit of value should be completely built and tested in a single sprint. When sprints are short, there ends up being a bias toward very small stories—and often a lack of focus on what value is actually being added with any given story or all the stories put together. (I suspect some of this has to do with the fact that companies and teams confuse "potentially releasable" with "we have to release every two weeks!")
I'm all for quick wins and getting features into customers' hands as fast as possible, but not all features—nor all worthwhile programming tasks—can be completed in a single sprint, no matter how long. That doesn't mean we shouldn't take on such challenging features; rather, we should be staggering them and balancing them with smaller features and bug fixes so that on average, each release is Just Right.