Empiricism in Agile – embracing change AND planning

Embracing change is at the heart of Scrum. The whole Agile philosophy is built around empirical, inspect and adapt approach. The Agile Manifesto contains statements like: “Responding to change over following a plan” or “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” It goes so deep, that we not only embrace change – we expect, or even desire it. We become suspicious of our process if the change doesn’t happen.

Yet, we want to have a well refined and ordered backlog. We want detailed user story acceptance criteria. We do a sprint planning and make a strong commitment of what goals we’ll achieve during the sprint. We even fight against changing these goals; the Scrum Guide states: “During the Sprint […] no changes are made that would endanger the Sprint Goal”.

A seeming contradiction

This dichotomy between planning and embracing change often causes misunderstanding and confusion.

On the one end of a spectrum, there is an attitude that the sprint review is more about an acceptance than feedback. If an increment produced at the end of a sprint doesn’t get “accepted” or if a review results in reorganizing the backlog, it means that we’ve failed requirement analysis, design or planning.

On the other end of a spectrum, there is an attitude that if we expect change after a review, a detailed requirement analysis, design and planning are waste and only slow-down our feedback loop.

Both attitudes are wrong.

How empiricism works?

The most important thing to understand is that empiricism doesn’t mean to try random things and see what happens. An empirical approach is deliberate and usually consists of following steps:

  • define a hypothesis
  • design an experiment that will validate or invalidate the hypothesis
  • run the experiment and gather results
  • evaluate the results
  • use newly acquired knowledge to define a new hypothesis or update the existing one

Understanding this process leads to several conclusions:

It’s good to design the next experiment in detail

A deliberate experiment requires a hypothesis: you must have expectations what should happen, under what conditions, and why. It also requires a plan: you must know in advance how to prepare and run the experiment, how to measure the results and how to evaluate them.

An alternative is to try random things and observe what happens. This is not utterly bad; it will also lead to some learning. In some cases, when the area of expertise is new to you and you can’t formulate a reasonable hypothesis, such approach may be even a better way to go. But most of the time, a deliberate experiment will result in a much faster rate of learning than a passive observation.

It’s bad to change conditions of an experiment in progress

Interfering with an experiment in progress will make its results unreliable, what in turn will make your initial hypothesis difficult to validate. It will also hinder your ability to evaluate and improve your process – an ability to learn how to formulate better hypotheses and design better experiments in future. Thus, an experiment should be “frozen”. Corrections should be applied in-between experiments, not in the middle of a one.

Of course, if you see that the experiment goes in a completely wrong direction, there’s no point in continuing it. But, in such a case, you should rather cancel the experiment, not try to redesign it on the fly.

It’s OK to invalidate a hypothesis

Our overarching goal is to discover a valuable innovation at the end of the whole series of experiments, not to be “right” with each one. Invalidating a “wrong” hypothesis can be often more valuable than confirming a safe, obvious one. “Failed” experiments are OK as long as they result in deliberate learning, that brings us closer to the final breakthrough – especially when they are short, and the cost of running a “wrong” experiment is low.

It’s good to plan a series of experiments in advance

An empirical approach is to run an experiment and use knowledge learned from this experiment to design the next, better one. But this doesn’t mean we’re obliged to think only one step ahead.

There’s seldom a situation, that only a single experiment is possible at a given moment. Usually, there’s a wide spectrum of experiments we can run, and we must choose the most valuable one – the one we can learn the most from. Creating a short backlog of possible experiments allows us to group and compare them, and prioritize them according to their learning potential. This, in turn, allows us to make better choices when selecting an experiment to run next, which results in a faster rate of learning, running less “failed” experiments, and, in effect, achieving a breakthrough faster.

It’s OK to re-plan the series of experiments

Although having a backlog of future experiments is good, we must understand that a backlog is not set in stone. An insight from running an experiment often inspires ideas for new experiments or makes some of initial experiment ideas obsolete.

But the fact that a backlog will change isn’t an argument against having a backlog, nor against investing an effort to keep it well refined and ordered. A well-maintained backlog supports the change because it makes it easier to assimilate insight from the last experiment and assess its value, and to discard whole groups of related experiment ideas when they become obsolete.

No contradiction at all

Embracing change and planning don’t oppose each other. It may seem counterintuitive at first, but a reasonable amount of analysis and planning, if done correctly, supports openness for change, not hinders it. It allows us to be more deliberate about change, to get more value from it, to be more flexible, not less.

But there’s a catch: to make planning help you stay open for change, you must be open to changing your plans.

What’s your sweet spot between planning and change? Do you embrace both, or do you lean more towards one of them? Please leave a comment and share your experience!


What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s