Team Problem Solving

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.

3 comments Write a comment

  1. My takeaway from Josh’s post was less that strategy should precede implementation and more that there are simply problems that need more than two weeks to solve, by any approach.

    I’m all for integrated teams and collaborative problem-solving, but not every problem is necessarily best solved with a sprint, regardless of how well that sprint is carried out.

  2. Pingback: Is design building interfaces or solving problems? - Bokardo

  3. The terminology often gets in the way, in my experience. The word “sprint” carries with it so much baggage, and so many organizations implement agile as a “development process” rather than a set of principles and rituals to run the entire product process by. As a result, the sensation is that anything that can’t be manifest as software isn’t a “story” and can’t be “in a sprint.” But, this is too narrow a way to use the methods of agile in my view, and some of the Scrum purists have only made matters worse by considering only something that can be manifest as a user-facing bit of value something worthy of going into a sprint. While focusing on the value to the humans using the software is certainly worth doing it can be too limiting to think of a sprint as needing to be only about moving the manifest software forward. To amplify Josh’s point, we often encourage teams to stop using the word “sprint” (in favor of “iteration” or other similar words) and to focus on the transparency, accountability, and predictable rhythm that comes from planning that way. In such a frame it’s no problem to put a design problem at the top of your backlog, the output of which may be to come to a satisfying answer (or even just to move on to better questions) rather than to commit some code. Any problem that takes longer than two weeks should be easily decomposed into intermediate steps that can be accomplished within the rhythm of your iterations. And if it turns out to take more than two weeks to digest that chunk that’s a great bit of learning that the team can discuss and learn from.

Leave a Reply

Required fields are marked *.