The Agile Architect

Dealing with Poorly Defined Problems in an Agile World

It is difficult to solve a problem if the problem itself cannot be stated clearly. How does one "create a compelling user experience that will double our sales" or "build me something really cool"? Our Agile Architect discusses why the first problem an agile team must often solve is to define the problem itself.

• By Mark J. Balbes, Ph.D.
• May 17, 2017

Agile teams often find themselves in the business of solving poorly defined problems. By poorly defined, I don't mean a poorly written story. Rather, I mean a problem that is stated in such a way that it is unbounded or poorly bounded by its very nature.

Winning!
There's an episode of "Two and a Half Men" that illustrates a poorly defined problem perfectly. In the scene, Charlie, the 40-something bachelor uncle is asking Jake, the 8-year-old innocent, what he wants for dinner. Jake ask back, "What do you have?" Charlie responds, "What do you want?" Jake asks again "What do you have?" And so it repeats.

In this case, Charlie is posing to Jake a broad question with no constraints. The problem space is unbounded. Jake, not knowing how to constrain the problem space (What foods do I like? How hungry am I? How fast do I want the meal to be ready?) tries instead to constrain the solution space. Tell me what's available and I'll pick. Charlie, not knowing how to constrain the solution space (What food is available? What am I willing to spend on the meal? Do we make the meal or go out?) puts the problem back on Jake.

How could the discussion have occurred in a more productive way? Like this:

Charlie: What do you want for dinner? (Proposes a solution -- dinner -- to a presumed but unstated problem.)

Jake: Well, I am quite hungry and I would like to eat quickly. (Defines and constrains the problem space.)

Charlie: We could make a microwave meal or we could go to a fast food restaurant. (Constrains the solution space.)

Jake: What microwave meals do we have? (Explores the solution space.)

Charlie: Mushroom pizza or frozen waffles.

Jake: I don't feel like mushrooms and I had waffles for breakfast. (Constrains the problem space further with his preferences which leads to a constraint of the solution space.)

Charlie: Sounds like we are going out.

Jake: Where can we go that's fast? (Reiterates part of the problem space, possibly indicating that satisfying his hunger quickly is a more important problem than satisfying his hunger completely.)

Charlie: There's a McDonald's and a KFC that are two minutes away. Everything else is at least 15 minutes away. (Constrains the solution space.)

Jake: Let's go to KFC. (Resolves the problem.)

As you've probably guessed, it can be difficult to determine whether something is part of the problem space or the solution space. Jake doesn't feel like mushrooms. This could be expressed as "I'm hungry for something that is not mushrooms." Or it can be a constraint on the solution: "Exclude any solution that includes mushrooms."

An observant person will recognize the difference between "I don't feel like" and "I don't like." It might be possible to find a solution that is so compelling that it will overcome Jake's weaker mushroom aversion stance. Often in the real world, this is where productive solutions occur and where people fail to look.

The same issue of poorly defined problems happen with development projects in at least two different ways:

1. The customer or product owner does not know what they want. In other words, they can't define the problem space. To compensate, they give extremely vague guidance to the team. For example, "Build me an app that will double my sales." (Obviously an extreme example, but I've seen it happen.) The team doesn't know why sales aren't already doubled. What are the features that could impact sales? Is this a marketing problem? A user experience problem? Perhaps the market is already saturated and this is an impossible request.
   
   In this case, rather than lamenting that the customer is asking a question that is impossible for the team to solve, it is incumbent on the team to help the customer constrain both the problem space and the solution space so they can make educated choices together. The first problem space that needs to be defined is the problem of defining the problem.


2. The customer asks for a specific solution to an unknown or poorly-known problem. "Host my app in the cloud." In this case, since the team doesn't know why the app should be hosted in the cloud, they have no constraints to help choose a hosting service. The solution space might look very different if the customer said "Host my app in the cloud so we can improve performance by 50 percent" versus "Host my app in the cloud so we can co-market with the hosting service." In the former case, the team might choose an unknown hosting service because it provides the best performance boost for their app. In the latter case, they may choose Amazon AWS or Microsoft Azure because brand recognition is more important than technical specs. In either case, the team has the opportunity to push back on the solution with different suggestions or probe the problem space further.
   
   In fact, "improve performance by 50 percent" is really a solution statement. A problem statement would be something like "our users perceive that our application is slow." The solution space could include actually speeding up the app, changing the user experience (for example, adding a fun animation or other distraction) so the app is not perceived to be slow, or changing the user experience completely so that the slow activity happens in parallel with other user activities.

Final Thoughts
Agile teams work best when they have full knowledge of the problem space and solution space. In order to build the optimal product, it is often necessary to display agility of motion throughout both spaces. Agile teams spend most of their time developing software that is focused on resolving a well-defined area in the solution space. An agile coach can help the team step back from the day-to-day rhythm of exploring the solution space to also explore the problem space.