Big changes, little changes
Some recent conversations have included questions around whether small changes or large changes are “better”. Unsurprisingly my answer was “it depends” 🙂
Even though our goal might be to achieve a big change, I would recommend making a series of small changes to get there because we might learn all sorts of things along the way, including whether we’re actually going in the desired direction (it’s possible our small change has taken us down a side road) and whether the goal is still the goal.
OK, but what kind of changes does this apply to? All, I think. For example, if the aim is to change the users’ experience by adding a new feature (that sounds like a big change) we would usually break it down into epics and stories, and maybe think about multiple releases … but we probably want to start with some experiments to see if we’re building something the users want, i.e. get feedback early. So the large change is broken into smaller changes (releases, epics) and then into even smaller changes (stories, experiments).
But how does the team learn to do this decomposition? Well, learning a new skill can be a big change, so let’s break it down into small changes too. There are different techniques, so pick one, learn it (e.g. read about it, watch a video) and practice – ideally this includes getting feedback from someone with experience of the technique.
This principle can also be applied to coding: small, frequent check-ins make it easier to spot problems – when a test fails you’re only looking through a few lines of code, not pages and pages. It also reduces the chance of merge conflicts because there’s less time between pull and commit, which means a lower probability of someone else changing the file you’re working on.
So, back to the original question: are small changes or large changes are “better”? Well, I think the answer is small changes are what enable you to make large changes, so it depends on whether you’re looking at the end goal or how you’re going to achieve it.