Stop Planning the Unplannable

One of the most common situations a Scrum team will find itself in is Uncertainty. Whether it's unclear requirements, a unique technical challenge or work processes that are not exhaustively defined - it feels like surprises are always lurking just around the next corner.

One strategy to react to these uncertainties is clearly defining all possible cases, researching all available options and discussing and clarifying all eventual meanings. This strategy includes more planning, more discussions, and as a result, hopefully more clarity.

In reality, it mostly leads to technical gold-plating, convoluted processes and a waterfallish process in which we try to plan for each eventuality before we start the actual work.

Why does this happen? One reason is that in absence of data, it is very difficult to discern the theoretical special case from the possible or even likely special case. Trying to solve each theoretically possible exception from what we would consider the norm will invariably lead to a maybe complete, but mostly completely overengineered solution (this is true both for technical and procedural solutions).

The other reason lies in the nature of complex work itself. Complex systems are by their nature impossible to predict. Our ideas of outliers, exceptions and possibilities are inherently flawed, based on our experiences and biases. Both can be useful to create heuristics, but we shouldn't confuse them with accurate predictions of how our environment will behave once we introduce our change to it.

In philosophy, defining your terms is a good strategy. In complex environments, it is brittle and will likely fail.

Instead of creating the perfect plan up front, create a protocol how you are going to react once the system behaves in a way you did not foresee or include in your plan.

How will your decision making look like? How will you communicate? And how will you know that you have encountered such an unforseen situation?

Creating a framework that allows you to move swiftly inside the space of your work will pay off more than trying to create "watertight" solutions for uncertain, unclear, and incompletely understood problems.