Recently I was in a team futurespective (like an Agile retrospective but focused on our next piece of work). We were each asked to write on a post-it note an answer to this question:
What is one thing the team should do to give ourselves the best chance of success?
My contribution was: be deliberate
I meant this: try not to do things out of habit, inertia or because they’re the default action. Come up for air. Ask yourself “is this the best use of my time right now?”, “is this still valuable?”, “have I learnt something since I started that suggests a different approach?”
And by talking this idea through with the team, I can be sure they’ll hold me to account when I don’t follow my own advice.
Away from the office, however, it’s up to me.
Easter Weekend Craft Experiment
In the UK we get two public holidays at Easter, giving us a four-day weekend. This year I wanted to spend at least some of the time productively, so I set goals of learning something new and completing a small craft project.
I decided to kill two birds with one stone and make something with my as-yet-unused beading loom. I found a project, got out the beads and thread, cleared a space to work, set up the loom and started to follow the instructions. But after an hour I hadn’t got very far. The process was fiddly, I was running out of patience with it and, based on the the small piece I had made, it wasn’t going to produce something I’d be happy with.
The default thing to do here, as any crafter will tell you, would be to keep going and waste another two hours on half-making some ugly thing, run out of time, and leave it in an unfinished state with a vague and unrealistic intention of coming back to it some day.
Somehow, though, I did manage to take a step back and think about what I was doing. Maybe it’s because we’d been chatting at work about the sunk cost fallacy just a few days before, but this one time I asked myself the question I’d ask a product team:
Is it worth continuing?
(Answer: no, of course not.)
Thinking about this from an Agile perspective, the hour hadn’t been wasted. I’d accidentally conducted an almost textbook agile experiment:
- Started with a hypothesis: “A beading loom project will be enjoyable and produce some acceptable piece of beadwork”
- Identified the biggest risks: 1. it won’t be enjoyable and 2. the resulting beadwork will be rubbish
- Designed the smallest, cheapest experiment to test those risks: got out the beading loom, some beads I already had and was prepared to sacrifice, and timeboxed (ok, that’s a lie, but let’s pretend I planned it this way) my initial effort to an hour
- At the end of the timebox, reviewed my progress and decided that a beading loom project was not a good way to spend any more of my Easter weekend.
I won’t pretend that I generally run my life outside of work according to agile principles. This example was notable because it was a break from my usual patterns.
I’ve already started on my next post about my hypocrisy as an agile practitioner and product owner who struggles with managing my own to-do list. The next thing to do is set aside some time to finish it, and then actually do it.