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.

[Here’s the video of the domino chain reaction]

4 Simple Steps

I was watching Henrik Kniberg’s keynote at AgileByExample 2016 and I liked his T-shirt (as well as his speech, of course)
It sounds like 4 Simple Steps, but clearly it’s not simple or everyone would follow them. The challenge is to find out what’s preventing some or all of these – how is the system holding us back? Is there value in doing some, or is it “all or nothing”?
Of course, the answer is it depends 🙂 It starts with having conversations and helping people see the challenges, or at least listening to whether they even see the challenges. There is no “right” answer but maybe there are some answers which are less than ideal.