Joshua Porter, writing recently on his blog, observed that “not all design problems are two weeks long.”
Porter makes a distinction in the post between design as production (“we need an interface for this”) and design as problem solving. He argues that production activities make sense in the sprint, but that problem solving, because it’s unpredictable and difficult to schedule, should be done ahead of time, before development sprints begin.
The assumption here is that all activities within a sprint are production activities. But software development too can be done in both production (“we need you to code this feature”) and problem-solving (“let’s sketch a prototype in code”) modes. And you can extend this characterization to product management as well: managing production (“we need to add this feature to this product”) is different from managing problem-solving (“what feature should we add to the product to solve this business problem?”).
A sprint is just a work period. Nothing about this interval requires that the team do production work within this interval. Teams can use this time to explore and to sketch together. Teams working in a Lean Startup or LeanUX context do just this: product managers sketch problems, designers sketch solutions, and developers sketch prototypes. Teams use these sketches (often called “MVPs”) to research and explore the solution space–and they do that together within the context of the sprint.
It’s understandable that Porter equates work within the sprint as production work. Many (if not most) teams working in an agile context are working in production mode. But this is a symptom of a less-than-agile process, in which business and design decisions are made in a waterfall way and then handed off to production developers. It’s possible for teams to bring a deeper collaboration to our work, to engage our colleagues in our design explorations, and to do this in an agile way.