Inspiration

I’m suffering from blogger’s block this weekend – I can’t think of a topic for a new post. I’ve jotted down lots of small things but nothing that I could write more than a paragraph on. But if I dig a bit deeper, I don’t think the topics are the problem – I just can’t conjure up enough excitement to give any of them enough attention. It’s a good thing I’m not getting paid to update this blog – a job comes with expectations and timelines, and trying to be creative under pressure is just not conducive to producing something worthwhile.

So how do developers cope when faced with a deadline? I remember when I was a developer that I often needed to leave a problem overnight before I could start to find potential solutions. But that was back in the bad old days of waterfall or plan-driven development – someone sets a deadline (usually an artificial one) and then we had to meet it.

How is an agile approach better? Here are a few things which spring to mind:

Deadlines are rare, but when there really is a deadline then the scope is variable. It ought to be obvious but I’ll spell it out because this should have been true in waterfall too but rarely was – if you fix all three sides of the iron triangle (time, cost & scope) then the only variable left is quality. Time is fixed because of the deadline; cost is the equivalent to the number of people working on it; so if you don’t allow scope to change then you’re basically forcing developers to cut corners. [I’m ignoring the argument for adding more people when the deadline looms – Fred Brooks covered this many years ago.]

Rather than adding people when it’s too late, why not start with two (or more) people working together from the beginning? Most companies require code changes be reviewed because they know having a second person look at a problem helps improve the quality … but collaborating on the design (when you’re tackling the problem) rather than reviewing the code (when you’ve picked a solution and gone down that route) results in an even better outcome. Having someone to discuss ideas with is so valuable that solo developers often use “rubber ducking” (yes, talking to a rubber duck!) as a way to clarify their thinking.

I find visualisation to be incredibly useful, for myself and when I’m sharing a concept with someone I’m coaching. When a team is discussing their confidence in meeting their sprint commitment, I find a burndown chart can challenge the overly-optimistic (“We’ll get it all done on the last day”) and lead to conversations with the product owner about relative priorities, expectations, etc. When discussing a new feature and how it will benefit the end-users, sketching the user interface may help build a common understanding, and story mapping can build empathy with the customer.

Frequent feedback can help too. Sometimes the enormity of a problem can be daunting, so break it down into more manageable pieces and take smaller steps towards the goal. Getting feedback on a small part of the challenge can be stimulating and provide inspiration for the next steps.

Please leave a comment: how do you cope when you hit a creative block?

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]