Its always time for tea (Oredev keynote)

Always time for tea

Last week I delivered the opening keynote at Oredev in Sweden: It’s always time for tea – lessons for Alice the software developer. I also picked up a whole bunch of questions – about agile, OKRs and tea – which I intend to answer here in the coming weeks.

This was a unique presentation, a challenge to put together but still a lot of fun to create and deliver. You see, the conference had an Alice in Wonderland theme so the challenge was to deliver an Alice themed keynote. Having read Alice twice in the last few years I knew immediately where to start: the Mad Hatter’s Tea Party.

The lessons I drew from Alice form a mini-manifesto which nicely describes much of my own philosophy when it comes to managing digital work.

Deadlines over estimates

‘Yes, that’s it,’ said the Hatter with a sigh: ‘it’s always tea-time, and we’ve no time to wash the things between whiles.’

Which nicely describes the life of technology creators. I argue that “it is always time for tea” is actually the natural state of things. When it is not “time for tea” we lack motivation; humans are bad at estimating time but good at working to deadlines. (See my old Notes on Estimation and More Notes on Estimation.)

Therefore we should organise our work processes around deadlines not estimates and structure our work in the expectation that we will not get time to make things good later.

Purpose over plans

“It doesn’t matter which way you go,” the Cheshire Cat tells Alice, “‘you’re sure to [get somewhere] … if you only walk long enough.”

In Through the Looking Glass the Mock Turtle concurs: “‘no wise fish would go anywhere without a porpoise. … , if a fish came to ME, and told me he was going a journey, I should say ‘With what porpoise?'”

Similarly, plans are not benign, plans have a dark side, they can be demotivating, demoralising, controlling and mislead us. Planning is essential but plans are downright dangerous.

We often overlook purpose, mission and outcomes in favour of following the plan and just “doing the backlog”. Yet out backlogs have become bottomless pits and burn-down charts are often burn-up charts.

At some level we are too busy doing stuff and earning money to think about the bigger questions but there is evidence that companies which focus on purpose and regard profits as a side-effect do better, and not just in the long-run.

Small over big

Everyone knows about Alice growing bigger, and smaller. Which echo’s “Kelly’s law of projects: “Inside every large project is a small project struggling to get out.”

The idea of doing small things comes up again and again: minimally viable products, prototypes, proof of concepts and so on. But we too often think big and fall for the old economies of scale myth.

Simplicity over complexity

With big comes complexity, which Alice discovers when the King invokes rule number 42:


Again and again we find complexity hides simple truths, we need to constantly work for simplicity.

Along the way I talk a bit about the nature of agile methods and explain that while SAFe may be agile it will never be lightweight.

I think it will be a while, if ever, before this presentation gets repeated but hopefully a video recording will be out before long. In the meantime you can get the slides.

After my presentations at Oredev, and over coffees, I picked up a few questions which I thought I’d answer in the next few blog posts. I hope you find this useful, and as ever, please leave a comment or get in touch to talk about these ideas more.