Hey, Jonathan, I like where you’re headed with this, and think that it will have utility for the right kinds of projects.
Most of the projects I work on (so, a very unscientific n=1 sample) aren’t designing apps and interfaces. Rather, they’re touching on organisational design, diverse communities of people affected by the project, and affecting it, classic wicked problems with no clear answer, and any given answer effectively changing the problem. The clients I work with are often big, complex organisations with a lot of players with skin in the game, and quite often, without the capacity to hand staff over for a solid week to participate in sprints. <frustration ensues> A lot of these projects use something similar to the Discovery-Alpha-Beta-Live process designed by the Government Digital Service in the UK and similar methodologies in use by the Digital Transformation Agency in Australia (where I live) and 18F in the US.
I think for those kinds of projects, longer research periods, including sprints (I love them) are both appropriate and necessary.
For lighter projects with less complexity, one or two sprints to roll through research, prototyping, testing, validation, rinse, repeat is completely appropriate.
There’s probably a happy medium between the two, that even for the complex projects might well offer productivity gains and efficiencies. It’s definitely something I’m tempted to experiment with.