This is a fascinating interview with David Heinemeier Hansson, of recent Hey.com fame. He makes the point that when building software, we shouldn’t try to estimate features and then fit them into two week sprints. Instead, it should be possible to determine the value of solving a particular problem and then set time boundaries on solving it. The timeframes needn’t be short two-week sprints as if often the case in scrum, but something more suited to solving the problem in hand, say 6 weeks.
His central theme is that software is more akin to creative projects like books or movies than big engineering projects like building a skyscraper. While I think there are some interesting ideas here, and as a practitioner of Scrum I am also keenly aware of how easy it can be to become dogmatic about the various ceremonies and systems it advocates so much so that you end up becoming less agile.
That said I think shorter iterations are useful when you are unsure of the value of a certain feature. Building the smallest MVP allows you to test the market in order to determine the value. The idea of setting a time budget and giving the team a couple of months to build out a feature without the overhead and bureaucracy that Scrum entails does seem incising however, and may be appropriate in some cases. I will try to keep this in mind as I develop projects in the future.