How to form a hypothesis is to start by stating the business outcome and problem.

For example, Our deployment success rate is declining at a steady rate and the client NPS score is decreasing as a result.

A possible root cause is that incident reviews are held with no actions taken from them.

This is one of many root causes, and the one chosen to be the most likely and effective if successfully addressed.

The hypothesis is therefore that IF WE ____(DO X)______ then the resulting impact will be ____(RESULT)_____ and therefore we will se a change in ______(MEASURE)______ that will address the business problem of _____(see above problem)__________.

Each hypothesis has action items that will result in TRUE CRITERIA and FALSE CRITERIA to help you validate your hypothesis by running a quick, and cheap experiment.

Experiment:

If we have a Brown Bag Lunch once a week, with Systems Engineers, Architects, and Developers present, where learnings from the Post Deployment Reviews are shared and unpacked, awareness and action can be taken into the teams, while allowing for informal collective sensemaking about the issues.

True criteria

We will see a reduction in deployment failures and uptake on learnings in Post Deployment Reviews.

False Criteria

Deployment failures will remain the same, or improve and then regress (failed fix because of unintended other consequences).

TIME BOX your experiment and review it afterward. This produces learning, collective sense-making, and a systematic approach to solving tough problems.

VERY IMPORTANT: Do not run experiments on people who were not part of the hypothesis formation. This is a violation of trust and causes change fatigue. People want to feel that they are involved in solving problems and will support and contribute when they are part of forming hypotheses and tests, while then executing the tests and assessing the result themselves (in other words: Retrospectives for example).