Agile is supposed to be an empirical process, but this tends to get lost in the mechanical application of agile practices or in the rush to get features out the door.
This empirical process should apply to both what we’re building i.e. the product but also to how we build it our ways of working, team, tools, etc.
Empiricism requires transparency so that inspection may occur and then drive adaption.
A product example would be: We have metrics that give us transparency regarding how customers are using our mobile app. We inspect those metrics frequently and then adapt our product backlog based on our learning.
A ways-of-working example would be: we have data giving us transparency about the number of defects making it to the staging environment, we inspect those metrics regularly and then adapt our ways of working for example with automated regression testing.
It’s helpful to think of both these inspection and adaption loops (product one and ways of working one) as applications of the scientific method. We start with observation, then formulate a hypothesis, conduct some experiments, analyze the data, and determine if the hypothesis is correct. In this way, we evolve the product or our way of working.
Next time you’re crafting a feature for the product backlog or considering an improvement action for your ways of working make sure to ask yourself “What is the hypothesis I’m testing here?” and “What data will prove or disprove my hypothesis?”
